SCR #3729 NCPCOM - rel3^ver4^ncpc01^20171231 30-DEC-17 rel3^ver4^ncpl01^20171231 SVNCPI - rel3^ver4^rel01^20171231 rel3^ver4^ncp01^20171231 rel3^ver4^obj01^20171231 NCPDTCL - $data01.s34ncpi.ncpi01da NCPDDDL - $data01.s34ncpi.ncpi01ds NCPDTAL - $data01.s34ncpi.ncpi01dt NCPDC - $data01.s34ncpi.ncpi01dc NCPDCOB - $data01.s34ncpi.ncpi01dx NCPDCB74 - $data01.s34ncpi.ncpi01dv NCPDFUP - $data01.s34ncpi.ncpi01dz Reference: Internal Symptom: N/A Problem: 3.4 NCPI00DS has incorrect numbering for newly added XNC-CTYP definitions. Change: Renumbered CTYP definitions in NCPI01DS source. Also Corrected the TCPIPPRO obeyform from TCPIPPROCESS to TCPIPPRO. Implementation: Install the new NCPCOM and the new SVNCPI objects. Stop and start the NCPCOM module and the SVNCPI module using the new objects. Dependencies: none SCR #3727 SVNCPI - REL3^VER1^REL22^20171201 08-DEC-17 - REL3^VER1^NCP19^20171201 - REL3^VER1^OBJ14^20171201 - REL3^VER1^RN11^20171201 SVNCPI - REL3^VER2^REL09^20171201 - REL3^VER2^NCP08^20171201 - REL3^VER2^OBJ09^20171201 - REL3^VER2^RN05^20171201 SVNCPI - REL3^VER3^REL07^20171201 - REL3^VER3^NCP06^20171201 - REL3^VER3^OBJ06^20171201 - REL3^VER3^RN04^20171201 SVNCPI - REL3^VER4^REL01^20171231 - REL3^VER4^NCP01^20171231 - REL3^VER4^OBJ01^20171231 - REL3^VER4^RN01^20171231 Reference: Case #02670838 Symptom: Customer had a higher than expected transaction volume hit the system, which caused queuing and invoked NOM on the interface to VISA. They then attempted to issue DELIVER PRO command from NCPCOM, that message queued up behind everything else and went into the NOM file. Problem: Customer did not have PARAM DELIVER-PRIORITY configured to set the msg^priority on the DELIVER message and there was no way to set the NOM override flag for DELIVER messages. Change: Added a new parameter "DELIVER-NOMOVERRIDE ON/OFF" for SVNCPI to provide the ability to set the DELIVER msg^nom^override flag in the message header. By default, all DELIVER messages have a msg^nom^override set to 0. If this parameter is specified it will apply to all deliver commands(PROCESS, STATION & DEST) on that node. Implementation: Install new SVNCPI object file. Edit the pathconf and add SET SERVER PARAM DELIVER-NOMOVERRIDE to each SERVER-NCPI-?? definition you want this to apply to. Stop all the NCPI servers from TACL. Shutdown the pathway system and obey PATHCOLD. Dependencies: None SCR #3730 SVNCS - rel3^ver1^sncs25^20180110 10-JAN-18 SVNCS - rel3^ver2^sncs10^20180110 SVNCS - rel3^ver3^sncs06^20171230 SVNCS - rel3^ver4^sncs01^20180110 Reference: Case #02635374 Symptom: When executing a STATUS STATION *, DETAIL or STATUS NODE *, DETAIL command from NCS, an invalid subscript error occurs (termination status 00003, termination substatus 00000) and exits the screen. Problem: The logic added in SCR 3687 to insure the wildcard STATUS STATION * and STATUS NODE * command fills the screen did not account for the "DETAIL" modifier. This caused the NCS requestor to send another request for additional data which then created an invalid subscript. Change: Added code to check to see if the "DETAIL" modifier was specified before invoking the logic added by SCR 3687. Implementation: Install updated SVNCS on the XPNET subvol. Freeze, stop, stop, thaw SERVER-NCS. Dependencies: None SCR #3733 OCAALL - $data01.u34oca.ocaa01as 03-MAR-18 OCAXMON - $data01.s34xmon.oca01as OCANLIB - $data01.n34nlib.oca00as Reference : 2716141 Symptom: *** ERROR *** OCA file ocaXPMON not found *** ERROR *** OCA file ocaNLIB not found Problem: The ocanlib was not moved to the 3.4 release subvol, and the ocaxmon file had a rel ver error also the ocaall file had a typo. Change: Made the appropriate changes above. Implementation: Move in the OCAALL, OCANLIB, OCAXMON into the subvol where the OCAALL file is being ran. Obey the OCAALL file. Dependencies: xpnet 3.4 Code Review: CR-XPNET-38 SCR #3736 SVNCPI - REL3^VER3^REL08^20180430 30-APR-18 - REL3^VER3^NCP07^20180430 - REL3^VER3^OBJ07^20180430 SVNCPI - REL3^VER4^REL02^20180430 - REL3^VER4^NCP02^20180430 - REL3^VER4^OBJ02^20180430 NCPDC - S33NCPI.NCPI03DC - S34NCPI.NCPI02DC NCPDCOB - S33NCPI.NCPI03DX - S34NCPI.NCPI02DX NCPDCB74 - S33NCPI.NCPI03DV - S34NCPI.NCPI02DV NCPDDDL - S33NCPI.NCPI03DS - S34NCPI.NCPI02DS NCPDFUP - S33NCPI.NCPI03DZ - S34NCPI.NCPI02DZ NCPDTAL - S33NCPI.NCPI03DT - S34NCPI.NCPI02DT NCPDTCL - S33NCPI.NCPI03DA - S34NCPI.NCPI02DA Reference: Case #02731635 Symptom: NCPCOM commands fail with various errors. ALTER LINE , OUTPUT Line output failed, object not found. ALTER LINE , ORIGINATE Line originate failed, int table invalid. ALTER LINE , PRTLUNAME Line prtluname failed, int err, bad cmd subtype. ALTER LINE , OSIMGR Line osimgr failed, int table invalid. ALTER LINE , POLLINT Line pollint failed, object not found. Problem: The CTYP (command type) for new commands added during XPNET 3.3 development (HINFO STATION, HSTAT STATION, HSTAT PROCESS, HSTAT LINK, HSTAT DEST) inadvertantly overlapped the above LINE command types which caused the wrong vty (variable type) and object type to be sent to the XPNET node. The new commands worked as expected, however, it caused the ALTER LINE commands to fail. Change: Changed HINFO STATION, HSTAT STATION, HSTAT LINK, HSTAT DEST and HSTAT PROCESS command types to be unique as they should have been to allow all commands to work as expected. Implementation: Install the new SVNCPI object and the NCPD* DDL's on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or from NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: XPNET 3.3 and 3.4. Code Review: CR-XPNET-39 SCR #3738 N24DEFS 15-Jun-18 N24SEG Reference: 2747282 Symptom: The EAUDPRO process would not start when created Problem: The XNLIB library was not being pulled in correctly when using the N24DEFS/N24SETUP Change: Added a new reference for XNLIB-CODE-LOCATION to the N24DEFS. Implementation: Replace N24DEFS and N24SEG on the XPNET subvol with the new version. Dependencies: XPNET 3.4 Code Review: CR-XPNET-042 SCR #3742 NCPCOM - REL3^VER2^NCPC14^20180810 10-aug-18 REL3^VER2^NCPL13^20180810 NCPCOM - REL3^VER3^NCPC10^20180810 REL3^VER3^NCPL09^20180810 NCPCOM - REL3^VER4^NCPC02^20180810 REL3^VER4^NCPL02^20180810 Reference: Case #2771963 Symptom: The info obeyform on the device was looping in ncpcom. Problem: A change was made in 3.2 which caused the info obeyform on the device to loop when this is ran in ncpcom. Change: Corrected the loop in ncpl to prevent this from occurring. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.2, 3.3, 3.4 SCR #3717 BASE - REL3^VER4^BASE^REL01^20180124 30-AUG-18 - REL3^VER4^DCOM01^20171231 - REL3^VER4^ONCF^SYS01^20171231 - rel3^ver4^dlib01^181230 Reference: Case - 2643850 Symptom: SSL Certificate file with zero EOF is held open by XPNET when accessed by altering a device to point to that file with the SSLCERTSFILE attribute. Problem: When loading the certsfile into the SSL memory segment within XPNET on an alter device SSLCERTSFILE command if the certsfile has a zero length the create segment fails and the file is not closed. Change: Added code to close the certsfile when a create segment call fails when loading a certsfile into the SSL memory segment within Xpnet. SCR #3718 BASE - REL3^VER4^BASE^REL01^20180124 30-AUG-18 - REL3^VER4^DCOM01^20171231 Reference: Case# 02538484 Symptom: Unable to route response messages from PWR station to INTFHI93 service (or other BASE24-eps services) when there are no local IS processes started on that node. 17-03-21;15:19:33.776 \SYS1.$E5XPB ACI.XPNET.3300 6124 Msg 783032: failed message cannot be returned (failure 110,src -1,dest 8194) 17-03-21;15:19:33.780 \SYS1.$E5PRB ACI.XPNTCTSS.1000 1160 PWR, Message Failure 2 from INTFHI93, Ignored. 17-03-21;15:19:33.781 \SYS1.$E5XPB ACI.XPNET.3300 6295 Station S5B^PWR^AMDP^01 sent message with invalid destination S5B^PWR^AMDP^01 Problem: When a message is routed over a LINK process to another node, msg^external^source is set to 1. This is done so that if the message cannot be routed to a local object/service provider on the destination node it is failed back to the sending node to be re-routed. This is to prevent the message from inadvertently looping and being routed to a third or fourth node and also to prevent routing errors if the third node does not have a started LINK process with the original sending node. In this case when the MHDR format macros are in use for the PWR station, when the response is sent back from the PWR process to the INTFHI93 service, it reused the header which still had msg^external^source set to 1. This does not cause a problem if there are local INTFHI93 service providers on that node, however, if there are no IS processes running on that XPNET Node and thus no local service providers, the message is failed with a 110 because the logic thinks the message originated on another node and it should not forward the message on to an external INTFHI93 service provider on another node. Change: Added logic in the station input MHDR format macro functionality to reset specific message header flags similar to SCR 3480 which did this for process input messages to prevent this problem. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none SCR #3726 BASE - REL3^VER4^BASE^REL01^20180124 30-AUG-18 - REL3^VER4^DCOM01^20171231 - REL3^VER4^ONCF^SYS01^20171231 - rel3^ver4^dlib01^181230 Reference: Internal Symptom: No symptom was discovered at customer sites. This was only discovered on internal ACI development systems marking/checkpointing functionality. Problem: The "marking tools" discovered a problem when adding a Process or Station through NCPCOM that has the same symbolic name as a destination that was previously added manually. A work area was modified and not "marked", thus causing the "marking tools" to identify that issue. Change: Added code to "mark" the work area that was modified. SCR #3743 SVNCSP24 - SVNCSP-NET24-33-04 30-aug-18 SVNCSP-NET24-34-01 SVNCSP - SVNCSP-33-04 SVNCSP-34-01 Reference: case #2770417 Symptom: Stack overflow when running SVNCSP. Problem: Customer was running SVNCSP with the Golden Gate library and ran out of room on the stack. Change: Moved some structures from the WORKING-STORAGE section to the EXTENDED-STORAGE section. Implementation: Install the new SVNCSP and SVNCSP24 modules on the xpnet subvolume. Dependencies: XPNET 3.3 and 3.4 Code Review: CR-XPNET-48 SCR #3748 PWS - rel3^ver0^pws07^181129 29-NOV-18 PATHTPLS - $data01.n30pws.pws03ps PATHTPLO - $data01.n30pws.pws03po Reference: 2793513 Symptom: The client sends a message to PWS which is sent to XPNET. The client gets a zero length reply and the response is queued at the XPNET station. Problem: The client is using the new SERVERCLASS_SENDL_ call. The maximum reply size parameter is set to a value larger than 32,767. PWS uses a signed integer for the parameter which causes the maximum reply size value in PWS to be a negative number. PWS thinks the client is asking for a zero length response. PWS replies immediately with a zero length response and doesn't read the response from XPNET. Change: Altered PWS to determine that the maximum reply size is invalid. If invalid, PWS replies to the client with an error 21 ( illegal count specified ) and generates event message 1341 indicating that the maximum reply count is invalid. Implementation: Restore the PATHTPLS and PATHTPLO files to the XPNET subvolume. Remake the XPNET templates using SCRIBE.TMPLMAKE, and then remake all EMS templates using the SCRIBE.GOINST macro. Install the new PWS module, Stop and restart the PWS process. Dependencies: None. Code Review: CR-XPNET-52 SCR #3745 XNCGEN - REL3_VER1_XNCG11_20181030 30-OCT-18 - REL3_VER2_XNCG02_20181030 - REL3_VER3_XNCG02_20181030 - REL3_VER4_XNCG01_20181030 Reference: Case #2771925 Symptom: It used to be the case that you could span processes on any desired system. However when I try to start the CTSE process by setting the Process Program attribute preceded by the remote System Id, the process abends. Problem: XNCGEN upshifted the Internal filename of the Default Startup subvol, the IN and OUT Startup file after it was resolved from the External filename. The Internal filename has a numeric representation of the system number. If the system number is in the range of an ASCII lower case alpabetic value the upshift will change the value of the system number. Change: The change made is to Up-shift the Exteranl filename before resolving to the Internal filename for the affected attributes. Implementation: Install new XNCGEN object file. Dependencies: none Code Review: CR-XPNET-xxx SCR #3749 SKELB - REL3^VER1^SUTL26^20181228 28-DEC-18 SKELLIST - $DATA01.N31SUTL.SUTL26TL SPRT01 - REL3^VER1^SPRT01^20181228 SPRT01B - SPROUTE 01 Bind File SPRT01BC - SPROUTE 01 Bind Obey File SPRTEXP - SPROUTE 01 Spooler Listing File Reference: case #2833509 Symptom: New Customer IIN ranges need to be added to skel and sproute per mandate Problem: New customer IIN ranges need to be added for sproute mapping. Change: Changes have been implemented in SKELB and in the Sprt** modules to add the new IIN ranges for the customer. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. Code Review: CR-XPNET-053 SCR #3728 BASE 3.3 - REL3^VER3^BASE^REL11^20190110 30-DEC-17 - REL3^VER3^AUD02^20181130 - REL3^VER3^EXEC05^20181130 - REL3^VER3^NSTP01^20181130 - REL3^VER3^PROC03^20180912 - REL3^VER3^ONCF^PRO01^20181130 - REL3^VER3^ONCF^SYS05^20181130 BASE 3.4 - REL3^VER4^BASE^REL03^20190110 - REL3^VER4^EXEC01^20181130 - REL3^VER4^PROC01^20180912 RTS - REL3^VER3^RTS01^20181130 - REL3^VER4^RTS01^20181130 SVNCPI - REL3^VER3^REL09^20181130 - REL3^VER3^NCP08^20181130 - REL3^VER3^OBJ08^20181130 - REL3^VER3^RN05^20181130 - S33NCPI.NCPRSP02 - S33NCPI.NETCMD03 - S33NCPI.NETRSP02 NCPDC - S33NCPI.NCPI03DC NCPDCOB - S33NCPI.NCPI03DX NCPDCB74 - S33NCPI.NCPI03DV NCPDDDL - S33NCPI.NCPI03DS NCPDFUP - S33NCPI.NCPI03DZ NCPDTAL - S33NCPI.NCPI03DT NCPDTCL - S33NCPI.NCPI03DA DDLC - S33SDDL.SDDL03DC DDLCOB - S33SDDL.SDDL03DX DDLFUP - S33SDDL.SDDL03DZ DDLS - S33SDDL.SDDL03DS DDLTAL - S33SDDL.SDDL03DT NCPCOM - REL3^VER3^NCPC11^20181130 - REL3^VER3^NCPL10^20181130 - REL3^VER3^RLBK02^20181130 - S33NCPL.PREL02TG - S33NCPL.PARS04TG - S33NCPL.NCPL03DS SVNCS - REL3^VER3^SNCS08^20181130 - REL3^VER3^NCPL10^20181130 - S33NCPL.PREL02TG - S33NCPL.PARS04TG - S33NCPL.NCPL03DS XPNCSP - REL3^VER3^NCSPCNFG^20171230 SVNCSP24 - SVNCSP-NET24-33-04 - SVTAB-A-33-02 NCSPREPT - NCSP-REPORT-REL33-04 - SVTAB-A-33-02 SVNCSP - SVNCSP-33-04 - SVTAB-A-33-02 NETCJRD - REL3^VER3^CJRP02^171230 Reference: Internal Symptom: N/A Problem: N/A Change: �� Moved module from the 3.4 enhancement effort to N33RTS RTS01TS. Assumptions made when intially developing RTS based on conversations with IR were changed in the 3.4 development cycle. Change Highlights: 1) Connection handling, all message types will be sent dowm each connection. This will allow Each RTS process to support up to 3 consumers. 2) Removed the initial message type. 3) Added Tcpretries handling for lost connections. 4) Added HSTAT message for the node. 5) Corrected the TCPIPPRO obeyform from TCPIPPROCESS to TCPIPPRO. Implementation: Install the new NCPCOM and the new SVNCPI objects. Stop and start the NCPCOM module and the SVNCPI module using the new objects. Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3740 BASE - REL3^VER1^BASE^REL43^20180712 12-JUL-18 - REL3^VER1^PROC18^20180912 BASE - REL3^VER2^BASE^REL15^20180912 - REL3^VER2^PROC04^20180912 BASE - REL3^VER3^BASE^REL11^20190110 - REL3^VER3^PROC03^20180912 BASE - REL3^VER4^BASE^REL03^20190110 - REL3^VER4^PROC01^20180912 Reference: Case #02751516 Symptom: XPNET abnormally terminates with trap #6665 after NCPCOM command ALTER NODE , BCPU (stopping and starting backup PIN) followed immediately by NCPCOM command SWITCH NODE . Problem: The issue is the checkopen of a file number (LINK or application PROCESS) had not completed successfully during the backup restart as the result of the ALTER BCPU before the SWITCH NODE command which performs a takeover was issued. This caused that backup to became the primary with that file number not open. As a result of this, the node dispatched an I/O tag to attempt to cleanup and reopen that file number for the LINK or application process. The issue was that it failed an internal sanity check (file number open but no I/O was in progress). Change: Updated the logic that caused trap #6665 (process file number is not zero and process output in progress is false) to also check the following: if the IOCB (I/O control block) for that file number = 0d and the error = 202 (takeover) then continue processing the cleanup/reopen instead of abending to handle this timing issue/sequence of events, otherwise abend with trap #6665. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: None SCR #3744 BASE - REL3^VER1^BASE^REL43^20180712 12-SEP-18 - REL3^VER1^EXEC21^20180912 - REL3^VER1^PROC18^20180912 BASE - REL3^VER2^BASE^REL15^20180912 - REL3^VER2^EXEC05^20180912 - REL3^VER2^PROC04^20180912 BASE - REL3^VER3^BASE^REL11^20190110 - REL3^VER3^EXEC05^20180912 - REL3^VER3^PROC03^20180912 BASE - REL3^VER4^BASE^REL03^20190110 - REL3^VER4^EXEC01^20180912 - REL3^VER4^PROC01^20180912 Reference: case #2794585 Symptom: XPNET node abends when starting an external process after altering its DEVICE XNCONF NODE 19 > START PROCESS TCPSRV^1^ZEXP1 Process \SYS1.P1A^NODE.TCPSRV^1^ZEXP1 start failed, file sys err: 201 Problem: The external process was previously DISABLED. When a process is disabled some specific logic is not invoked (and should not be). Part of this is fixing up the data related to the device and XPCONF associated with that process. When the process was ENABLED, the node did not properly "fix up" all of the data and pointers and left the address pointing to its device invalid (0d). The logic to start the process assumed the pointer was valid, accessed the device data for this process and caused an invalid address trap in subproc LOAD^XNCPRO^DATA in proc PROCESS^CONTROL^TASK. Change: Updated the logic when the ENABLE PROCESS command is invoked to properly "fix up" its data and pointers. This will prevent the address trap from occuring. Also added logic in subpro LOAD^XNCPRO^DATA to validate the process device address before attempting to access it to prevent possible future abends. If the process device address is not set, the START PROCESS command will fail and event 2122 will be generated: 18-09-13;10:49:00.564 \SYS1.$P1AN ACI.XPNET.3300 2122 Process TCPSRV^1^ZEXP1 XNCONF error 19031 (Fixup of the XNconf entry for this process failed) Previous STARTING, Current ABNORMAL Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3751 BASE - REL3^VER4^BASE^REL02^20181130 29-JAN-19 - REL3^VER4^ONCF^DEST01^20190129 Reference: Case #2857317 Symptom: NETWORK Trap #0011 due to execution of commands STATUS DEST #DIAG-DEST and HSTAT DEST #DIAG-DEST Problem: Logic added in XPNET 3.4 to support new (external) audit internal dests #AUDIT-SERVICE, #AUDIT-CONTOL and #AUD-EXT-STATS incorrectly assumed the address of the dest entry was valid (not set for #DIAG-DEST) and attempted to access data within that structure causing the address #0011 trap. Change: Added additional logic to make sure the dest address is set before attempting to access data within that structure. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.4. Code Review: CR-XPNET-058 SCR #3750 BASE - rel3^ver3^base^rel12^20190125 25-jan-19 NSTP - rel3^ver3^nstp02^20190125 BASE - rel3^ver4^base^rel04^20190125 NSTP - rel3^ver4^nstp01^20190125 GLOBAL - N33GLBL.GLBL03TG GLOBAL - N34GLBL.GLBL02TG Reference: Case #2806197 Symptom: The release information is incorrect. Problem: in log #7019 the XPNET release is showing incorrectly shows Release 3.20 instead of Release 3.30 or 3.40 Change: corrected the release in the globals Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.3, XPNET 3.4 SCR #3753 CTSE - REL3_VER0_CTSE33_021519 15-FEB-19 TCPCLI - REL3_VER0_TCPC60_021519 TCPSRV - REL3_VER0_TCPS65_021519 SSLSRV - REL3_VER0_SSLS43_021519 SSLCLI - REL3_VER0_SSLC42_021519 Reference: Case #2857175 Symptom: Many ZZSA files during startup of new CTS stations. Problem: On startup of the SSLCLI process the primary was able to open the supplied STDOUT file, it then closes it. The primary then proceeds to start the backup process. On startup the backup process CRE library tries to open STDOUT and fails causing the code to ABEND. The SSLCLI receives a "Process deletion system message" and tries to restart the backup. This continues, saveabends are produced until the open is successful or no more saveabends can be created. Change: Code was added to configure a backup retry param. This param is used when a "Process deletion system message" for the backup is received. If the backup retry param is not zero the primary will try to open STDOUT. If the backup retry param is zero then the primary will set the backup to disabled. Each failed attempt to open STDOUT will decrement the backup retry param. New Param was added: Param BKUPRETRY default = 5. GOTCPCLI/SRV setting of new param: param bkupretry 8 Tell command added for #BKUPRST tell external $gcli.#BKUPRST, "BKUPRETRY 6" New log messages 19-02-27;16:38:44.438 \NODE.$GCLI ACI.XPCTSE.3000 1027 Backup Retries will be 5 times. 19-02-27;16:33:24.942 \NODE.$GCLI ACI.XPCTSE.3000 1027 Backup Retries will be 8 times. 19-02-27;16:34:48.830 \NODE.$GCLI ACI.XPCTSE.3000 1029 Backup Retries reset to 6 times. 19-02-27;16:34:48.830 \NODE.$GCLI ACI.XPCTSE.3000 1020 Backup enabled. Implementation: Move in the new SSL/TCP modules. Stop associated XPNET stations. Stop and re-start SSL/TCP processes. Re-start the previously stopped stations. Dependencies: none SCR #3754 TCPCLI - REL3_VER0_TCPC60_021519 15-FEB-19 SSLCLI - REL3_VER0_SSLC42_021519 Reference: Case #02861262 Symptom: XPNET TCPCLI Abends with out error. Problem: An invalid IP address was configured in the raddr for a CTS Client station. ex. 0.xx.xx.xx. For HP TCPIPv6 and Conventional stacks the invalid raddr was accepted, the CONNECT_NW() was done without error. However due to the invaold IP addr eventually returned a 4126 ETIMEOUT error which is a retryable error. In the case of a CLIM stack a error 4022 EINVAL is returned on a CONNECT_NW() this error was coded to abend. Change: Intial coding of the TCPCLI process incorporated the EINVAL error code for debugging purposes. The change is to remove the EINVAL error code from the abend logic and handle it as a retryable error. Implementation: Move in the new SSL/TCP modules. Stop associated XPNET stations. Stop and re-start SSL/TCP processes. Re-start the previously stopped stations. Dependencies: none SCR #3756 BASE - REL3^VER4^BASE^REL05^20190412 12-APR-19 - REL3^VER4^AUD01^20190412 BASE - REL3^VER3^BASE^REL13^20190412 - REL3^VER3^AUD03^20190412 BASE - REL3^VER2^BASE^REL16^20190412 - REL3^VER2^AUD02^20190412 BASE - REL3^VER1^BASE^REL44^20190412 - REL3^VER1^AUD08^20190412 Reference: 02890104 Symptom: XPNET node abends with a trap 6538 in fesclose after altering AUDIT OFF. Problem: Logic added by SCR 3688 did not account for the possibility the audit file number could be negative (fesopen returns a -1 in the file number if the open fails for any reason). If the file number was not 0 it attempted to close it. The logic in fesclose did not expect a file number with an negative value and failed a sanity check and abended. Change: Changed the logic added by SCR 3688 to only close the audit file if the file number is greater than 0. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-63 SCR #3760 NCPCOM - REL3^VER1^NCPC30^20190503 06-MAY-19 REL3^VER1^NCPL27^20190503 NCPCOM - REL3^VER2^NCPC15^20190503 REL3^VER2^NCPL14^20190503 NCPCOM - REL3^VER3^NCPC12^20190503 REL3^VER3^NCPL11^20190503 NCPCOM - REL3^VER4^NCPC03^20190503 REL3^VER4^NCPL04^20190503 Reference: Cases 2871369 and 2881007 Symptom: When obeying an obeyform file attempting to add a device, results are unpredictable following a SET statement containing MACRO and the device is not added. Problem: An uninitialized pointer could cause random issues. Change: Properly initialized the pointer. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.1, 3.2, 3.3, 3.4 Code Review: CR-XPNET-66 SCR #3761 NCPCOM - REL3^VER2^NCPC15^20190503 03-MAY-19 REL3^VER2^NCPL14^20190503 NCPCOM - REL3^VER3^NCPC12^20190503 REL3^VER3^NCPL11^20190503 NCPCOM - REL3^VER4^NCPC03^20190503 REL3^VER4^NCPL04^20190503 Reference: cases 2885028 Symptom: When obeying an obeyform file with a ,cpu the file loops. Problem: A display needed to be increased. Change: Increased the display field in ncpl. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.2, 3.3, 3.4 Code Review: CR-XPNET-66 SCR #3764 OCANCPI - $DATA01.S34NCPI.OCA01AS 23-MAY-19 OXANCPI - $DATA01.S34NCPI.OXA01AS OCANCPI - $DATA01.S33NCPI.OCA01AS OXANCPI - $DATA01.S33NCPI.OXA01AS OCANCPI - $DATA01.S32NCPI.OCA02AS OCANCPI - $DATA01.S31NCPI.OCA01AS Reference: Case #02902380 Symptom: SVNCPI object is being accelerated with OCAX. OCAX/out $S.#oxa.SVNCPI, name / SVNCPI, output_file SVNCPIA, obey ZZoxa04 *** ERROR *** OCAX failed with completion code 1 See $S.#oxa.SVNCPI for error information. OCAX - T0892L01 - (Apr 8 2017 08:36:06) Copyright 2017 Hewlett Packard Enterprise Development LP. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 2. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 3. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 4. Problem: New warnings from the acceleration of SVNCPI. Change: Updated the OCANCPI and OXANCPI to remove warnings. OXANCPI #append oxa_cmds INHERITSR2 SEC^GUARD^VERIFY^CPC #append oxa_cmds INHERITSR3 SEC^GUARD^VERIFY^CPC #append oxa_cmds INHERITSR4 SEC^GUARD^VERIFY^CPC OCANCPI #append oca_cmds INHERITSR2 SEC^GUARD^VERIFY^CPC #append oca_cmds INHERITSR3 SEC^GUARD^VERIFY^CPC #append oca_cmds INHERITSR4 SEC^GUARD^VERIFY^CPC Implementation: Install updated OCANCPI and OXANCPI and obey the macro. Dependencies: none Code Review: CR-XPNET-69 SCR #3757 SVNCPI - REL3^VER4^REL04^20190424 24-APR-19 - REL3^VER4^SEC01^20190424 SVNCPI - REL3^VER3^REL10^20190424 - REL3^VER3^SEC03^20190424 SVNCPI - REL3^VER2^REL10^20190424 - REL3^VER2^SEC02^20190424 SVNCPI - REL3^VER1^REL23^20190424 - REL3^VER1^SEC05^20190424 Reference: Case #02768094 Symptom: SERVER-NCPI abends when executing a DELIVER command with the CPCONF in use. Problem: There was an uninitialized pointer on the stack in procedure SEC^GUARD^WARMBOOT^CPC. This happened to point at the beginning of the memory pool and corrupted the memory pool header. Once this occurs, any call to pool_getspace_ causes SVNCPI to trap and abend. Stack trace could be one of the following: Num Lang Location ABEND 0 TAL #TRAP^DUMP.#1528(DLIB00TS) + %10I 1 TAL #MEMPOOL^ALLOC.#354(MEM00TS) + %15I 2 TAL #LIST^OBJ^CONS.#947(UT00TS) + %7I 3 TAL #OBJECT^POP^GET^PATT^LIST.#4970(OBJ11TS) + %3I 4 TAL #COMMAND^EXEC_INIT.#5298(NCP11TS) + %142I 5 TAL #COMMAND^EXEC.#4912(NCP11TS) + %7I 6 TAL #REQUEST^EXEC^COMMANDS.#19102(NCP11TS) + %23I 7 TAL #LINK^INIT^REQUEST.#16077(NCP11TS) + %6I 8 TAL #RCV^USER^MSG.#17931(NCP11TS) + %6I 9 TAL #REL4^VER0^NCP00^20191230.#4314(NCP11TS) + %6I Num Lang Location ABEND 0 TAL #EVT^CONS.#830(EVT00TS) + %3I 1 TAL #RN^CONNECT_CREATE^NCPCOM.#3072(RN01TS) + %20I 2 TAL #TRAP^DUMP.#1521(DLIB00TS) + %5I Change: Changed the code to use a local variable on the stack in procedure SEC^GUARD^WARMBOOT^CPC instead of a pointer. Found the same problem in procedure SEC^GUARD^VERIFY^CPC so fixed that as well. Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or from NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: none Code Review: CR-XPNET-64 SCR #3763 XPNCSP - REL3^VER4^NCSPCNFG^20190516 16-MAY-19 SVNCSP - SVNCSP-34-02 - SVTAB-A-34-01 SVNCSP24 - SVNCSP-NET24-34-02 - SVTAB-A-34-01 NCSPREPT - NCSP-REPORT-REL34-01 - SVTAB-A-34-01 Reference: Case #02902380 Symptom: When testing SCR 3762 was unable to secure EXTAUDQMI via the XPNCSP program. Problem: The internal table was loading the wrong VTY for this entry. Change: Corrected the code to use the VTY associated with EXTAUDQMI. Also deprecated EXTAUDEXT, EXTAUDIT and EXTAUDMAXEXT which were not implemented. Implementation: Install new modules on the XPNET subvol. Dependencies: none Code Review: CR-XPNET-68 SCR #3762 SVNCPI - REL3^VER4^REL05^20190516 16-MAY-19 - REL3^VER4^NCP04^20190521 - REL3^VER4^OBJ04^20190516 - REL3^VER4^SEC02^20190516 - REL3^VER4^RN02^20190516 - REL3^VER4^BKUP01^20190516 SVNCPI - REL3^VER3^REL11^20190516 - REL3^VER3^NCP09^20190521 - REL3^VER3^OBJ09^20190516 - REL3^VER3^SEC04^20190516 - REL3^VER3^RN06^20190516 - REL3^VER3^BKUP02^20190516 SVNCPI - REL3^VER2^REL11^20190516 - REL3^VER2^NCP09^20190521 - REL3^VER2^OBJ10^20190516 - REL3^VER2^SEC03^20190516 - REL3^VER2^RN06^20190516 - REL3^VER2^BKUP02^20190516 Reference: Case #02902380 Symptom: XPNET34 EXTAUD* params give error when ONCF security is enabled and access should be allowed. ALTER NODE *, EXTAUDPRI $TEST.P1ANAUDP Node \SYS1.P1A^NODE extaudpri failed, invalid security. Problem: The new attributes added under XPNET 3.4 are secured in the second NCSP record. SVNCPI was only looking in the first NCSP record, so the command was not found and failed security. Change: Added logic to check the second NCSP record if the command is not found in the first NCSP record. Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or From NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: None Code Review: CR-XPNET-67 SCR #3765 SVNCPI - REL3^VER4^REL06^20190620 20-JUN-19 - REL3^VER4^NCP05^20190620 - REL3^VER4^EVT01^20190620 - REL3^VER4^MEM01^20190620 - REL3^VER4^OBJ05^20190620 - REL3^VER4^RN03^20190620 - REL3^VER4^SEC03^20190620 - REL3^VER4^TIM01^20190620 - REL3^VER4^UT01^20190620 - REL3^VER4^BKUP02^20190620 SVNCPI - REL3^VER3^REL12^20190620 - REL3^VER3^NCP10^20190620 - REL3^VER3^EVT02^20190620 - REL3^VER3^MEM02^20190620 - REL3^VER3^OBJ10^20190620 - REL3^VER3^RN07^20190620 - REL3^VER3^SEC05^20190620 - REL3^VER3^TIM02^20190620 - REL3^VER3^UT02^20190620 - REL3^VER3^BKUP03^20190620 SVNCPI - REL3^VER2^REL12^20190620 - REL3^VER2^NCP10^20190620 - REL3^VER2^EVT02^20190620 - REL3^VER2^MEM02^20190620 - REL3^VER2^OBJ11^20190620 - REL3^VER2^RN07^20190620 - REL3^VER2^SEC04^20190620 - REL3^VER2^TIM02^20190620 - REL3^VER2^UT03^20190620 - REL3^VER2^BKUP03^20190620 Reference: Case #02902380 Symptom: NCPCOM commands fail with the following error: PATHSEND error 904, server link error (Guardian error 201) SVNCPI creates saveabend file with the following stack: Num Lang Location ABEND 0 TAL #PROGRAMMATIC^DUMP.#1454(DLIB00TS) + %10I 1 TAL #BKUP^CHECKPOINT.#909(BKUP01TS) + %4I 2 TAL #REL3^VER4^NCP04^20190521.#4246(NCP04TS) Problem: Changes added by SCR 3762 to support the second NCSP record increased the size of the globals in SVNCPI. This caused the call to checkpointmanyx during backup creation to fail because the stackbase + globals increased to 34,496 bytes which is above the 32,500 limit for non native applications. This causes SVNCPI to call abend. This only occurs when the SVNCPI is configured to run with a backup. In the server definition in the pathconf the CPUS attribute has two CPU numbers specified. Change: Added logic to create a new flat segment for the memory required for the NCSP records instead of in globals. Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or From NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: None Code Review: CR-XPNET-70 SCR #3766 BASE - REL3^VER4^BASE^REL06^20190805 05-AUG-19 - REL3^VER4^ONCF^PRO01^20190805 BASE - REL3^VER3^BASE^REL14^20190805 - REL3^VER3^ONCF^PRO02^20190805 Reference: Case 2935064 Symptom: There is a XNCONF defined to a satellite process (XPNETSTARTUPSEQ ON). After the process is started the following command is issued: INFO PRO *,DEVICE The network abends in the proc shown below. Notice the address for INFO^RSP^ is zero: #11 0x704854e0 in BUILD^PRO^INFO^RESP (PRO^=0x60ecbdb8, INFO^RSP^=0x0) at \OMA3T06.$DATA01.N34ONCF.PRO00TS:1515 Problem: A call to PROCESS_GETINFOLIST_ passed the wrong return value max length. It was twice as large as it should have been. Prior to the X.86 this didn't cause an issue. On the X.86 it caused it to walk on the INFO^RSP^ address. Change: Modified the call to PROCESS_GETINFOLIST_ to pass the correct length for the return value max length field. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-72 SCR #3767 SVNCSP - SVNCSP-34-03 20-AUG-19 - SVTAB-A-34-02 SVNCSP24 - SVNCSP-NET24-34-03 - SVTAB-A-34-02 NCSPREPT - NCSP-REPORT-REL34-02 - SVTAB-A-34-02 SVNCSP - SVNCSP-33-06 - SVTAB-A-33-03 SVNCSP24 - SVNCSP-NET24-33-06 - SVTAB-A-33-03 NCSPREPT - NCSP-REPORT-REL33-05 - SVTAB-A-33-03 Reference: Case #02926884 Symptom: Unable to secure PROCESS attributes REMOTEADDR2, REMOTEADDR3 and REMOTEPORT1 in the NCSP file. Problem: When the new logic in the TABA module was added to support these new attributes, the table index was not incremented properly causing them to not be added to the table and not referenced on the screen. Change: Fixed the logic to properly increment the index. Implementation: Install new modules on the XPNET subvol. Dependencies: none Code Review: CR-XPNET-073 SCR #3768 RTSSAT - rel3^ver4^rts03^20190822 22-AUG-19 RTSSAT - rel3^ver3^rts03^20190822 Reference: Case #02947303 Symptom: Duplicate stations showing in Prognosis display. Problem: The NonStop Node in RTS header contained trailing spaces in state change messages and nulls in the status change messages. This caused prognosis to detect these as different objects. The logic in the RTS process did not properly initialize the variable being used to store the NonStop Node name and if it was less than 8 characters there could be nulls/garbage in the field which was then moved into the RTS header. The RTS state change messages are created in the XPNET Node which properly cleared out the field and insured it was filled in for the actual node name length instead of 8 as the RTS process was. Change: Modified the RTS process to properly initialize the NonStop Node name and only move the system name for its actual length. Implementation: Install new modules on the XPNET subvol. Dependencies: none Code Review: CR-XPNET-074 SCR #3770 BASE - REL3^VER4^BASE^REL07^20190911 11-SEP-19 - REL3^VER4^QUE01^20190911 GLOBAL - N34GLBL.GLBL03TG BASE - REL3^VER3^BASE^REL15^20190911 - REL3^VER3^QUE01^20190911 GLOBAL - N33GLBL.GLBL04TG BASE - REL3^VER2^BASE^REL17^20190911 - REL3^VER2^QUE02^20190911 GLOBAL - N32GLBL.GLBL08TG BASE - REL3^VER1^BASE^REL45^20190911 - REL3^VER1^QUE09^20190911 GLOBAL - N31GLBL.GLBL19TG Reference: Case #02940233 Symptom: XPNET Node abends with a trap #11 after QWRITE command in procedure QWRITE^CMD^IT^TIMER + 0xC80 (UCr) when it was moving the [0,0] EOF marker to the file. Problem: The XPNET logic moving the last EOF marker was using an INT .EXT pointer instead of a STRING .EXT pointer. This caused extra bytes to be moved past the actual EOF of the named file. This only causes an issue if the actual size of the file (named QWRITE segment) ends on a 16k boundary ( i.e. 32768, 65535 ). The underlying memory allocated (by Guardian) for the segment is created using 16k blocks. If the EOF is on a 16k boundary, the move goes past the end of the memory and causes the address trap. If the EOF is not on an exact 16k boundary, there is slack at the end of the file/memory block and no trap occurs. Change: Changed the logic to use a STRING .EXT file address pointer which prevents the move from going past the EOF. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-075 SCR #3771 BASE - REL3^VER4^BASE^REL07^20190911 11-SEP-19 - REL3^VER4^QUE01^20190911 BASE - REL3^VER3^BASE^REL15^20190911 - REL3^VER3^QUE01^20190911 BASE - REL3^VER2^BASE^REL17^20190911 - REL3^VER2^QUE02^20190911 Reference: Case #02927208 Symptom: XPNET abends in procedure ENQUEUE when attempting to process and ADD NODE command. Problem: The XPNET process was unable to open the NEF file (error 48) so it did not set the address of the NDF pointer and was generating an EMS event to indicate the open failed, called ENQUEUE to queue the event message to the internal log queue. The logic in ENQUEUE checked to see if it should update the MAX QUEUE COUNT TIMESTAMP if @NDF <> -1d. The issue was @NDF was set to 0D, so attempted to access the NDF and trapped. Change: Added an additional check to make sure @NDF <> 0d before attempted to access it. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-076 SCR #3773 BASE - REL3^VER4^BASE^REL08^20191130 30-NOV-19 - REL3^VER4^DCOM03^20191130 BASE - REL3^VER3^BASE^REL16^20191130 - REL3^VER3^DCOM05^20191130 BASE - REL3^VER2^BASE^REL18^20191130 - REL3^VER2^DCOM08^20191130 Reference: Case #2929387 Symptom: BASE24-eps 2.1.11 (NSK-X) - Since migration to NSK X machine TXN STATS Entry Time is invalid. Problem: A variable that is not initialized and is referenced after a possible path in which it is not updated. On the Itanium it is always set to Zero prior to the decision point. On the X86 the value varies. It is referenced after the decision point assuming that it would be Zero if not updated Change: Intialize the variable to Zero at declaration. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none SCR #3758 XNCGEN - REL1_VER0_XNCG00_20191230 30-DEC-19 CPCGEN - REL1_VER0_CPCG00_20191230 RPCGEN - REL1_VER0_RPCG00_20191230 Reference: Internal Symptom: For many years XPNET has been using an older version of the open source ExPat XML Parser which has known security (CVE) vulnerabilities. Problem: Every time a new version of XPNET was released or a new CVE was reported it created additional work and issues in ACI's third party vulnerability tracking and management to mark them as not applicable. XPNET is not using the parser in a web facing role, so those vulnerabilities do not pose a risk from a security standpoint. Change: It was determined that XPNET's requirements were limited and upgrading to the current version of the ExPat XML parser was not needed. In addition, we would still face the same issues if any new CVE's were reported. So an internal XML parser was written and the open source version was removed from XNCGEN, RPCGEN and CPCGEN to avoid the overhead associated with maintaining a third-party open source module. Implementation: Install the updated versions of CPCGEN, RPCGEN and XNCGEN. Dependencies: None. Applies to all versions of XPNET. Code Review: CR-XPNET-82. SCR #3776 CTS - REL3^VER4^CTS01^20200219 19-FEB-20 - REL3^VER3^CTS03^20200219 - REL3^VER2^CTS03^20200219 - REL3^VER1^CTS15^20200219 Reference: case #2935333 Symptom: - Node Dump with Trap Dump 6559 when INPUT OFF/ON Command set on Line Problem: If a connection exists and the station is stopped/ aborted the code does not initialize conn^cb.conn^id. If a Disable Input is done on the line cts^send^disable^input^sig^rcv is called which transitions the code into the closed state and signals the RECV FSM to stop. When the Enable Input is done on the line cts^send^enable^input^sig^rcv is called. In this proc a check is done on the conn^cb.conn^id. If this is set to a valid connection id the code will incorrectly signal a start. This causes the code to post a RECV when the filenum is set to -1 which causes the dump 6559. The filenum was correctly set to -1 when the stations was stopped. Change: Set the conn^cb.conn^id to -1 once the line nc pending has occurred. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. Code Review: CR-XPNET-89 SCR #3772 SUTL - rel3^ver4^sutl02^20190927 27-SEP-19 SUTL - rel3^ver3^sutl03^20190927 SUTL - rel3^ver2^sutl06^20190927 SUTL - rel3^ver1^sutl27^20190927 Reference: Case #02959487 Symptom: VISA abended for unknown reason. Problem: The log^messageX code is doing signed moves which causes an arithemetic overflow when the data pointer passed in by the calling routine is over 32735 and under 32763. Change: Modified the SUTL log^messageX code to move the pointer using unsigned moves. Implementation: Since SKELB is run aa user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: none Code Review: CR-XPNET-xxx SCR #3777 SKELB - REL3^VER1^SUTL28^20200320 20-mar-20 SKELLIST - $DATA01.N31SUTL.SUTL28TL SPRT01 - REL3^VER1^SPRT0x^20200320 SPRT01B - SPROUTE 0x Bind Fileisting File SPRT01BC - SPROUTE 0x Bind Obey File SPRTEXP - SPROUTE 0x Spooler Listing File Reference: case:na Symptom: New Customer IIN ranges need to be added to skel and sproute per mandate Problem: New customer IIN ranges need to be added for sproute mapping. Change: Changes have been implemented in SKELB and in the Sprt** modules to add the new IIN ranges for the customer. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. Code Review: CR-XPNET-090 SCR #3781 04/09/20 BASE - REL3^VER3^BASE^REL17^20200409 - REL3^VER3^ONCF^STA04^20200409 BASE - REL3^VER4^BASE^REL09^20200409 - REL3^VER4^ONCF^STA02^20200409 BASE - REL4^VER0^BASE^REL01^20200409 - REL3^VER4^ONCF^STA01^20200409 Reference: Case #02799744 Symptom: Unable to Alter Station Param SBRDISTGLOBAL. Problem: Protocol CTS was not supported for this attribute Change: Modified the STATION code to include CTS as a supported Protocol. Implementation: Install the new BASE file on the XPNET subvol Rebuild the NETWORK object using the NETBC file. Stop and start Resource Nodes using the new NETWORK object. Dependencies: none SCR 3780 04/07/2020 SVNCPI - REL4^VER0^OBJ01^20200407 - REL4^VER0^REL01^20200407 - s40ncpi.ncprsp01 SVNCPI - REL3^VER4^OBJ06^20200407 - REL3^VER4^REL07^20200407 - s34ncpi.ncprsp01 SVNCPI - REL3^VER3^OBJ11^20200407 - REL3^VER3^REL13^20200407 - s33ncpi.ncprsp03 Reference : #2959405 Symptom: Statistics station * shows TCP stations as temporary Problem: The NCPRSP table has a previous release value in the latest version. Change: Change was made in NCPRSP01 to include the current release Implementation: Install the new SVNCPI object on the XPNET subvol Accelerate SVNCPI using OCA macro (OCANCPI) for Itanium and (OXANCPI) for X.86 platforms to avoid performance issues. From TACL: STOP or from NCPCOM: DELIVER NODE ,"ABORT-NCPI" Dependencies: none Code Review: CR-XPNET-95 SCR #3784 04/17/20 SVNCPI - REL3^VER3^REL14^20200417 - REL3^VER3^OBJ12^20200417 - s33ncpi.netcmd04 SVNCPI - REL3^VER4^REL08^20200417 - REL3^VER4^OBJ07^20200417 - s34ncpi.netcmd01 SVNCPI - REL4^VER0^REL02^20200417 - REL4^VER0^OBJ02^20200417 - s40ncpi.netcmd01 Reference : #3076629 Symptom: LOGN Total counter doesn't clear on the RESETSTATS NODE , COUNTERS command Problem: The latest version of the NETCMDxx file mapped that command to ncp^vty^mod^none instead of ncp^vty^mod^counters Change: Changed the table to use ncp^vty^mod^counters Implementation: Install the new SVNCPI object on the XPNET subvol Accelerate SVNCPI using OCA macro (OCANCPI) for Itanium and (OXANCPI) for X.86 platforms to avoid performance issues. From TACL: STOP or from NCPCOM: DELIVER NODE ,"ABORT-NCPI" Dependencies: None. Code Review: CR-XPNET-98 SCR #3785 SVNCPI - rel4^ver0^rel03^20200427 27-APR-20 rel4^ver0^ncp01^20200427 SVNCPI - rel3^ver4^rel09^20200427 rel3^ver4^ncp06^20200427 Reference: #2936503 Symptom: SERVER-NCPI-xx doesn't start Problem: SERVER-NCPI-XX does not start when PARAM DELIVER-PRIORITY 65535 Change: Made a code change to support the unsigned integer range (32768 to 65535). Implementation: Install the new SVNCPI object. Accelerate SVNCPI using OCA macro (OCANCPI) for Itanium and (OXANCPI) for X.86 platforms to avoid performance issues. From TACL: STOP or from NCPCOM: DELIVER NODE ,"ABORT-NCPI" Dependencies: None Code Review: CR-XPNET-99 SCR #3792 06/08/20 jb NCPCOM - rel4^ver0^ncpl01^20200608 - rel4^ver0^ncpc01^20200608 SVNCS - rel4^ver0^sncs01^20200608 NCPCOM - rel3^ver4^ncpl05^20200608 - rel3^ver4^ncpc04^20200608 SVNCS - rel3^ver4^sncs02^20200608 NCPCOM - rel3^ver3^ncpl12^20200608 - rel3^ver3^ncpc13^20200608 SVNCS - rel3^ver3^sncs09^20200608 Reference: cases 03099494 Symptom: When obeying an obeyform file with MACRO attribute INPUTFORMAT and OUTPUTFORMAT don't get populated. Problem: SCR 3760 initialized a pointer but did not fill it with the correct value. Change: Added code back that filled the pointer's location Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.3, 3.4, 4.0 Code Review: CR-XPNET-105 SCR #3793 06/16/2020 jb EAUDPRO - rel3^ver4^eaud01^20200616 EAUDPRO - rel4^ver0^eaud01^20200616 Reference: 03106414 H24-131670 Symptom: When a new audit file is created by external audit process, it unregister his service from xpnet node Problem: Calculation for percentage is done within a variable too small to hold the max size of bytes^used * 100. Change: Created new float variables to do the calculation and put the result into the existing field. Implementation: Stop all AUDPRO processes, move the new EAUDPRO object onto the XPNET subvolume and restart EAUDPRO as appropriate. Dependencies: None Code Review: CR-XPNET-107 SCR #3799 08/14/2020 jb NETADRD -REL3^VER3^audr01^20200814 NETADRD -REL3^VER4^audr01^20200814 NETADRD -REL4^VER0^audr01^20200814 NETADRT -REL4^VER0^audt01^20200814 Reference: H24-166300 03141495 Symptom: NETADRD Prints Type 9 record to the screen but does not put it in the QWRITE file Problem: When 9 was used for PURGE and POP, it was not included in NETADRD as a TYPE that can use QWRITE Change: Added type 9 to QWRITE logic. Implementation: Install the new NETADRD program. Dependencies: None Code Review: CR-XPNET-110 SCR #3786 05/01/2020 jb BASE - REL3^VER3^BASE^REL18^20200501 - REL3^VER3^EXEC06^20200501 - REL3^VER3^MMGR01^20200501 BASE - REL3^VER4^BASE^REL10^20200501 - REL3^VER4^EXEC02^20200501 - REL3^VER4^MMGR01^20200501 BASE - REL4^VER0^BASE^REL02^20200501 - REL4^VER0^EXEC01^20200501 - REL4^VER0^MMGR01^20200501 Reference: INTERNAL Symptom: NETWORK abends out of memory. Problem: 1) The Station control block not being released when the station is deleted with non-cts protocols. 2) The allocators^id^to^name table missing literals. Change: 1) Removed the protocol check before calling the routine that deletes the control block. 2) added missing literals to the table. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-106 SCR #3798 08/15/20 BASE - REL4^VER0^BASE^REL04^20200820 - REL4^VER0^ONCF^SYS02^20200820 NCPCOM - REL4^VER0^NCPC02^20200820 - REL4^VER0^NCPL02^20200820 BASE - REL3^VER4^BASE^REL11^20200820 - REL3^VER4^ONCF^SYS02^20200820 NCPCOM - REL3^VER4^NCPC05^20200820 - REL3^VER4^NCPL06^20200820 BASE - REL3^VER3^BASE^REL19^20200820 - REL3^VER3^ONCF^SYS06^20200820 NCPCOM - REL3^VER3^NCPC14^20200820 - REL3^VER3^NCPL13^20200820 Reference: H24-99772 Symptom: The SSLMED attribute was not correctly populating when the node restarted. Problem: There were some original coding omissions for the SSLMED/ SSLMAT attributes that were not behaving as expected. Change: Code was changed to update the SSLMED/SSLMAT attributes to work as the expected behavior. Implementation: Install the new BASE file on XPNET subvol and rebuild the NETWORK object using the NETB file. Install the new NCPCOM on the XPNET subvol and stop and restart NCPCOM. Dependencies: XPNET 3.3, 3.4, and 4.0 Code Review: CR-XPNET-109 SCR #3801 N24SEG - $DATA01.U33N24S.N24S03AS 06-Oct-20 N24SEG - $DATA01.U34N24S.N24S04AS N24SEG - $DATA01.U40N24S.N24S02AS Reference: Internal Symptom: Running out of low pins on the system. Problem: There are too many processes running low pin. Change: To help alleviate the problem, N24SETUP will now create the TCP process to have HIGHPIN set to ON. Implementation: Replace N24SEG on the XPNET subvol with the new version. Dependencies: XPNET 3.3. 3.4 and 4.0 Code Review: CR-XPNET-111 SCR #3803 mmn OCT-23-20 SKELB - REL3^VER3^SUTL05^20201023 SKELLIST - REL3^VER3^SUTL05^20201023 POBJ - T3270-LMCF-PCI (D42) 26 OCT 2020 10:28:01 - T6520-LMCF-PCI (D42) 26 OCT 2020 10:27:55 SKELB - REL3^VER4^SUTL04^20201023 SKELLIST - REL3^VER4^SUTL04^20201023 POBJ - T3270-LMCF-PCI (D42) 26 OCT 2020 10:35:16 - T6520-LMCF-PCI (D42) 26 OCT 2020 10:35:10 SKELB - REL4^VER0^SUTL02^20201023 SKELLIST - REL4^VER0^SUTL02^20201023 POBJ - T3270-LMCF-PCI (D42) 26 OCT 2020 10:40:25 - T6520-LMCF-PCI (D42) 26 OCT 2020 10:40:19 Reference: Internal (XPNET-779) Symptom: (ISO) Board announced its intent to migrate from the current six-digit IIN to an eight-digit standard. IINs are the six-digit numeric assets assigned to card-issuing financial institutions. Problem: XPNET only allows for a max of 6 characters of the PAN prefix and 4 characters of the suffix to be shown in EMS events when implementing PCI masking via the LMCF (See SCR 3440). Change: Changed the PCI LMCF requestor to allow 999 to be entered in the PAN DIGITS field, verses previous limit of 694. Changed SKELB to support these new values. To support backward compatibility, if PAN length is in the previous range 13 - 19 then the previous mask rule enforced - prefix max of 6 and suffix max of 4 displayed depending on max mask length and prefix length. If the length of the PAN passed to log^message is greater than 19 and less than 29 then new mask rule enforced - prefix max of 9 and suffix max of 9 displayed in EMS depending on max mask len and prefix length. Implementation: SCUP COPY the updated LMCF-PCI requester into your working POBJ. Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Accelerate the SKELB module via the OCASKELB or OXASKELB. Update the PAN DIGITS in the appropriate LMCF records. Dependencies: none Code Review: CR-XPNET-115 SCR #3809 12/31/2020 mmn RTSSAT - rel3^ver4^rts07^20201211 - rel4^ver0^rts01^20201211 Reference: Case #03211752/H24-232890 Symptom: RTS (Real Time Stats) Process abends after an object (Process, Link, Station, Destobj) was deleted. Problem: The internal object tables are managed/indexed via an array of pointers. When an object is added, it is assigned an index (object number) using an empty entry in the array, filling in the address of that object. When an object is deleted, its memory is returned and its entry/index in the object table array is zeroed out so it can be reused. The XPNET node accounts for this when accessing the object tables. However in several places the RTS process did not properly account for empty slots in the middle of the object table(s) which results in an address trap when it attempts to set the address of the object and reference a field within its structure. Change: Fixed the logic so that it properly skips the empty slots when accessing the object tables to send out status messages. Implementation: Install updated RTS object and restart the RTS processes. Dependencies: none Code Review: CR-XPNET-120 SCR #3810 01/11/2021 jb NCPCOM - rel3^ver4^ncpc06^210111 SVNCS - rel3^ver4^sncs03^210111 - $data01.s34ncpl.ncpl07ts NCPCOM - rel4^ver0^ncpc03^210111 SVNCS - rel4^ver0^sncs02^210111 - $data01.s40ncpl.ncpl03ts Reference: INTERNAL CHANGE Symptom: TCPLISTENPORT does not get populated by OBEYFORM when numbers above 32767. Problem: A signed comparison was done where a unsigned one was neeeded. Also pulled in the latest NCPLib file as it was not up to date for SVNCS. Change: Changed the comparision to be unsigned. included the newest library for NCPCOM and SVNCS. Implementation: Move the new files into XPNET subvol and restart NCPCOM and/or SVNCS. Dependencies: none Code Review: CR-XPNET-123 SCR #3795 07/14/20 jb Reference: BASE - REL3^VER3^BASE^REL20^20200901 - REL3^VER3^SEG01^20200901 BASE - REL3^VER4^BASE^REL12^20200901 - REL3^VER4^SEG01^20200901 BASE - REL4^VER0^BASE^REL06^20200901 - REL4^VER0^SEG01^20200901 Symptom: Network abend when clearing RPC from device when audit is on and processing traffic for the station. Production (NS2200) B Node Abnormality Problem: Stations associated with lines that are disabled do not get device RPC changes which can cause invalid pointers. Change: Added code to segment^delete^by^dev so it will remove the RPC and XNC files from all stations disbaled or enabled. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-123 SCR #3808 12/14/2020 jb BASE - REL3_VER3_REL20_201214 - REL3_VER3_DCOM06_201214 - REL3_VER3_STA05_201214 BASE - REL3_VER4_REL12_201214 - REL3_VER4_DCOM04_201214 - REL3_VER4_STA03_201214 BASE - REL4_VER0_REL06_201214 - REL4_VER0_DCOM02_201214 - REL4_VER0_STA02_201214 Reference: 03176663 H24-234267 Symptom: Dynamic station issues from customer testing. Problem: PREFIX is truncated when it creates dynamic stations/lines Using RADDR causes more stations to be created then asked for. Naming convention for lines/stations isn't consistent. Change: Added logic to allow PREFIX to be variable length. added logic to disallow RADDR with TEMPLATE. added logic to use "S" as the first character of a station like "L" is used in the first character of a line. Implementation: Move in the new BASE module. Stop XPNET template & temporary stations. restart the node start XPNET template stations (it will start temp stations) Dependencies: none Code Review: CR-XPNET-123 SCR #3814 03/15/2021 BASE - REL4^VER0^BASE^REL08^20210315 - REL4^VER0^NSPT01^20210315 BASE - REL3^VER4^BASE^REL13^20210315 - REL3^VER4^NSPT02^20210315 Reference: H24-277709 3260342 Symptom: After backup takeover the RTS process dumps and goes abnormal. Problem: RTS segment in XPNET is not updated on a XPNET Hot backup takeover. Change: Added code to update the RTS segment on an XPNET Hot Backup takeover. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none Code Review: CR-XPNET-127 SCR #3816 03/23/2021 jb NCPCOM - rel3^ver3^ncpc15^20210323 SVNCS - rel3^ver3^sncs10^20210323 - rel3^ver3^ncpl14^20210323 NCPCOM - rel3^ver4^ncpc07^20210323 SVNCS - rel3^ver4^sncs04^20210323 - rel3^ver4^ncpl08^20210323 NCPCOM - rel4^ver0^ncpc05^20210323 SVNCS - rel4^ver0^sncs04^20210323 - rel4^ver0^ncpl05^20210323 Reference: H24-253627 03234219 Symptom: QVIEW DETAIL when more than a page is needed to display the message makes NCPCOM abend. Problem: There wasn't code to handle a single message that was longer then a page. Change: Added logic to continue to display past the one page limit of previous releases. Implementation: Move the new files into XPNET subvol, restart NCPCOM and/or SVNCS. Dependencies: none Code Review: CR-XPNET-129 SCR #3817 3/26/2021 jb SKELB - REL3^VER3^SUTL06^20210326 SKELLIST - REL3^VER3^SUTL06^20210326 SKELB - REL3^VER4^SUTL05^20210326 SKELLIST - REL3^VER4^SUTL05^20210326 SKELB - REL4^VER0^SUTL03^20210326 SKELLIST - REL4^VER0^SUTL03^20210326 Reference: H24-278984 03261735 Symptom: 8 Digit BIN does not get displayed when PAN is less than 20 digits long. Problem: An invalid assumption was used during developement and based on that the change did not affect the PAN's with lengths that are less then twenty Change: Removed code that set the prefix based on the size of the PAN to allow for 8 digit BIN's to be displayed with the same size PAN's as were used with 6 digit BINs. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Accelerate the SKELB module via the OCASKELB or OXASKELB. Update the PAN DIGITS in the appropriate LMCF records. Dependencies: none Code Review: CR-XPNET-130 SCR #3819 07/08/21 jb BASE - REL3^VER3^BASE^REL21^20210708 REL3^VER3^EXEC07^20210708 REL3^VER4^BASE^REL14^20210708 REL3^VER4^EXEC03^20210708 REL4^VER0^BASE^REL09^20210708 REL4^VER0^EXEC03^20210708 CTS - REL3^VER3^CTS04^20210708 REL3^VER4^CTS02^20210708 REL4^VER0^CTS02^20210708 IPCL - REL3^VER3^IPCL07^20210708 REL3^VER4^IPCL06^20210708 REL4^VER0^IPCL03^20210708 IPSC - REL3^VER3^IPSC08^20210708 REL3^VER4^IPSC06^20210708 REL4^VER0^IPSC03^20210708 Reference: H24-328773 03316277 Symptom: Node went abnormal and abended after deleting a line. Problem: A restart timer had been set for that line before it was deleted, so when the timer popped and we attempted to access the line, it was gone. Change: Added code to remove the timer when a line gets deleted (CTS, IPCL, and IPSC were all affected by this) Implementation: Move in the new modules. Rebuild the NETWORK object using the NETB file. Restart the NETWORK processes. Dependencies: none Code Review: CR-XPNET-134 SCR #3826 11/12/21 jb BASE - REL3^VER3^BASE^REL22^20211112 - REL3^VER3^ONCF^SYS07^20211112 BASE - REL3^VER4^BASE^REL15^20211112 - REL3^VER4^ONCF^SYS03^20211112 BASE - REL4^VER0^BASE^REL10^20211112 - REL4^VER0^ONCF^SYS03^20211112 BASE - REL4^VER1^BASE^REL01^20211112 - REL4^VER1^ONCF^SYS01^20211112 Reference H24-368422 Symptom: NETWORK unable to close the trace file. Problem: When more than one trace is started, the previous file is not closed until the network is restarted. Change: Made starting a second trace an error. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None Code Review: CR-XPNET-144 SCR #3827 11/16/21 jb RELPROC - $data01.u10relp.relp00as Reference Internal Symptom: Compiled date/time not for the module listed. Problem: ENOFT and XNOFT return an error when trying to list source on some modules, causing us to be off when pulling from the various _list variables. Change: Added code to recongize the error condition and report no data for that module. Removed 700 code logic and moved the module to U10RELP. Implementation: Install the new files on the XPNET subvol. Dependencies: None Code Review: CR-XPNET-145 SCR #3829 11/30/2021 mmn OCAALL - U41OCA.OCAA01AS - U40OCA.OCAA01AS - U34OCA.OCAA02AS OXAALL - U41OCA.OXAA01AS - U40OCA.OXAA01AS - U34OCA.OXAA02AS OCAAPPL - U41ALIB.OCA01AS - U40ALIB.OCA01AS - U34ALIB.OCA01AS OXAAPPL - U41ALIB.OXA01AS - U40ALIB.OXA01AS - U34ALIB.OXA01AS OCAAUDP - U30AUDP.OCA01AS OXAAUDP - U30AUDP.OXA01AS OCAEMSP - N30EMPP.OCA03AS OXAEMSP - N30EMPP.OXA01AS OCAMQSI - N31MQSI.OCA01AS OXAMQSI - N31MQSI.OXA01AS OCANCP - S41NCPS.OCA01AS - S40NCPS.OCA01AS - S34NCPS.OCA01AS OXANCP - S41NCPS.OXA01AS - S40NCPS.OXA01AS - S34NCPS.OXA01AS OCANCPI - S41NCPI.OCS02AS - S40NCPI.OCS01AS - S34NCPI.OCA02AS OXANCPI - S41NCPI.OXA02AS - S40NCPI.OXA01AS - S34NCPI.OXA02AS OCANETAD - N41AUDR.OCA01AS - N40AUDR.OCA01AS - N34AUDR.OCA01AS OXANETAD - N41AUDR.OXA01AS - N40AUDR.OXA01AS - N34AUDR.OXA01AS OCANLIB - N41NLIB.OCA01AS - N40NLIB.OCA01AS - N34NLIB.OCA01AS OXANLIB - N41NLIB.OXA01AS - N40NLIB.OXA01AS - N34NLIB.OXA01AS OCAPATH - N21PATH.OCA02AS OXAPATH - N21PATH.OXA01AS OCAPREG - S41PRE.OCA01AS - S40PRE.OCA01AS - S34PRE.OCA01AS OXAPREG - S41PRE.OXA01AS - S40PRE.OXA01AS - S34PRE.OXA01AS OCAPWR - N21PWR.OCA01AS OXAPWR - N21PWR.OXA01AS OCAPWS - N30PWS.OCA02AS OXAPWS - N30PWS.OXA01AS OCAQFI - N30QFI.OCA02AS OCAQFILD - N30QFI.OCAL01AS OXAQFI - N30QFI.OXA01AS OXAQFILD - N30QFI.OXAL01AS OCASKELB - N41SUTL.OCA01AS - N40SUTL.OCA01AS - N34SUTL.OCA01AS OXASKELB - N41SUTL.OXA01AS - N40SUTL.OXA01AS - N34SUTL.OXA01AS OCATCPC - U10TCPC.OCA01AS OXATCPC - U10TCPC.OXA01AS OCATCPS - U10TCPS.OCA01AS OXATCPS - U10TCPS.OXA01AS OCAUDP - N30UDP.OCA01AS OXAUDP - N30UDP.OXA01AS OCAXMON - S41XMON.OCA02AS - S40XMON.OCA02AS - S34XMON.OCA02AS OXAXMON - S41XMON.OXA02AS - S40XMON.OXA02AS - S34XMON.OXA02AS OCAXNLIB - U41XLIB.OCA01AS - U40XLIB.OCA01AS - U34XLIB.OCA01AS OXAXNLIB - U41XLIB.OXA01AS - U40XLIB.OXA01AS - U34XLIB.OXA01AS Reference: Internal Symptom: In some cases, incorrect versions of the OCA/OXA macros were executed causing errors to occur. Problem: Old or incorrect versions of the macros were executed depending on the order of items in the users #PMSEARCHLIST or if #DEFAULTS was not configured. Change: Changed the OCA and OXA macros to look for files on the current volume and subvol [#DEFAULTS/CURRENT/] and not be dependent on the users #PMSEARCHLIST to work correctly. Implementation: Install the updated OCA and OXA macros on the XPNET subvol and obey them (from the XPNET subvol). As part of this, a copy of the OCABUILD and OXABUILD macros were installed on the XNLIB and SCRIBE subvols. Dependencies: None. Code Review: CR-XPNET-146 SCR #3830 12/07/2021 mmn BASE - REL4^VER1^BASE^REL02^20211207 - REL4^VER1^NSTP01^20211207 - REL4^VER1^EXEC01^20211207 BASE - REL4^VER0^BASE^REL11^20211207 - REL4^VER0^NSTP02^20211207 - REL4^VER0^EXEC04^20211207 BASE - REL3^VER4^BASE^REL16^20211207 - REL3^VER4^NSTP03^20211207 - REL3^VER4^EXEC04^20211207 BASE - REL3^VER3^BASE^REL23^20211207 - REL3^VER3^NSTP03^20211207 - REL3^VER3^EXEC08^20211207 GLOBAL - n41glbl1.glbl01 GLOBAL - n40glbl1.glbl01 GLOBAL - n34glbl1.glbl04 GLOBAL - n33glbl1.glbl05 NETTPLS - n41ems.ems01ps - n40ems.ems01ps - n34ems.ems01ps - n33ems.ems01ps NETTPLO - n41ems.ems01po - n40ems.ems01po - n34ems.ems01po - n33ems.ems01po NETETCL - n41ems.ems01ea - n40ems.ems01ea - n34ems.ems01ea - n33ems.ems01ea NETEC - n41ems.ems01ec - n40ems.ems01ec - n34ems.ems01ec - n33ems.ems01ec NETEDDL - n41ems.ems01es - n40ems.ems01es - n34ems.ems01es - n33ems.ems01es NETETAL - n41ems.ems01et - n40ems.ems01et - n34ems.ems01et - n33ems.ems01et NETECOB - n41ems.ems01ex - n40ems.ems01ex - n34ems.ems01ex - n33ems.ems01ex Reference: Case 3367557, 3367446 Symptom: Multiple error 30's generated on various processes and stations. 21-11-18;13:32:00.643 \PROD.$P1AN ACI.XPNET.3300 6200 A Guardian writeread error 30 (unable to obtain main memory space for a link control block) to Process P1A^REF2 occurred 21-11-18;13:32:00.644 \PROD.$P1AN ACI.XPNET.3300 2105 Station S1A^L1^0098 on Line L1A^L1^0098 closed because of a fatal Guardian error 30 (unable to obtain main memory space for a link control block), station will remain closed. Previous STARTING, Current ABNORMAL Problem: The number of started processes and stations caused the number of outstanding incoming messages to the XPNET node and or the number of outstanding messages sent by the XPNET node to exceed the values (4095) passed to CONTROLMESSAGESYSTEM resulting in error 30's on various file opens in the node. This can happen when too many objects are configured and started in a single XPNET node. Although the number configured is below the architectural limit of 4095 per object type, there is a practical limit that may require you to add an additional XPNET node and move some of these processes/stations to the new node. Change: Increased the values passed to CONTOLMESSAGESYSTEM from 4095 to 16383. This should prevent the error 30's, however, there is still a practical limit that may require you to horizontally scale by adding additional XPNET nodes and spreading out the configuration of processes and stations. If not, instead of error 30's, the XPNET node could start to experience PFS issues (error 31 Unable to obtain file-system buffer space). In addition to increasing the values 16383, a new EMS event (4058) has been added that will be generated as part of the XPNET statistics to display the data returned from MESSAGESYSTEMINFO which will externalize the current numbers in use in that XPNET node. 21-12-14;12:53:40.646 \PROD.$P1AN ACI.XPNET.4100 4058 CONTROLMESSAGESYSTEM STATS: INPUT MAX 16383 CURR 101; OUTPUT MAX 16383 CURR 104 Implementation: Install the new BASE file on the XPNET subvol and rebuild the NETWORK using the NETB file. Install the new NETTPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None. SCR #3844 05/10/22 jb and mmd NETTPLS - N41EMS.EMS02PS NETTPLO - N41EMS.EMS02PO TCPTPLS - U10TCPL.TCP04PS TCPTPLO - U10TCPL.TCP04PO Reference Internal Symptom: XPNET should not indicate HPE available features. Problem: Log message indicates versions of CLIM needed. Change: Changed log message to inform the user to check with HPE, and added them to the external TCPIP programs as well. Implementation: Install the new NETTPLS file and the new TCPTPLS/O files and re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None Code Review: CR-XPNET-158 SCR #3845 05/19/22 jb PATH - rel2^ver1^path08^051922 Reference H24-418370 Symptom: 4.1 version of PATH causes same condition as seen for 3833 Station goes ABNORMAL. Problem: The new 4.1 CTS structures were not updated in PATH Change: Updated PATH to use the new structures. Implementation: Put the new file in the XPNET subvol and restart The PATH executalbes from pathway. Dependencies: No dependencies. Code Review: CR-XPNET-160 SCR #3846 05/19/22 des BASE - REL3^VER4^BASE^REL17^20220519 REL3^VER4^DCOM05^20220519 REL3^VER4^ONCF^LIN01^20220519 BASE - REL4^VER0^BASE^REL12^20220519 REL4^VER0^DCOM04^20220519 REL4^VER0^ONCF^LIN01^20220519 BASE - REL4^VER1^BASE^REL04^20220519 REL4^VER1^DCOM01^20220519 REL4^VER1^ONCF^LIN01^20220519 Reference H24-383111 Symptom: When starting a template station when in the logical state of STOPPED, NCPCOM would sometimes report the station was already started: STATION 218 > start *dyn* Station S1B^DYN^3397 start failed, dsts tmpl sta already started. When starting a template station's line, NCPCOM would sometimes report the line name conflicts with a node: STATION 225 > start line *dyn* Line L1B^DYN^3397 start failed, obj name conflicts with a node. Problem: In the first condition, when the template station is originally started, a flag is set that doesn't get reset when stopped. When restarted that flag is checked which would normally indicate it's already started. In the second condition, when temporary stations are created and the template station is stopped, the temporary stations are left running, which is correct behavior. When the template line or station is restarted, the code attempts to create new temporary stations and it starts at 0000 which sometimes already existed, thus the duplicate object error. Change: In the first condition, the flag which indicates the station was once started now gets reset when it is stopped. In the second condition, the code has been changed to recognize that stations were already created. When the template line or station is restarted it creates temporary stations starting with where it left off. Implementation: Install the new BASE files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-159 SCR #3847 06/02/22 des NCPCOM - REL3^VER4^NCPC08^20220602 REL3^VER4^NCPL09^20220602 NCPCOM - REL4^VER0^NCPC07^20220602 REL4^VER0^NCPL07^20220602 NCPCOM - REL4^VER1^NCPC02^20220602 REL4^VER1^NCPL02^20220602 Reference H24-419487 Symptom: Server Listener line attribute TCPCONNTIMEOUT is not being displayed correctly on INFO or OBEYFORM commands when set to -1. Problem: Code was displaying a -1 as 65536 on an INFO command. In the OBEYFORM output, the value wasn't being displayed at all. Change: Properly display -1 in both the INFO and OBEYFORM commands. Implementation: Move in the new NCPCOM code and stop any NCPCOM processes that are currently running and restart them. Dependencies: No dependencies. Code Review: CR-XPNET-161 SCR #3850 06/12/22 des BASE - REL3^VER4^BASE^REL18^20220612 REL3^VER4^LIN02^20220612 BASE - REL4^VER0^BASE^REL13^20220612 REL4^VER0^LIN02^20220612 BASE - REL4^VER1^BASE^REL05^20220612 REL4^VER1^LIN02^20220612 Reference H24-383111 Symptom: Using temporary stations, when you initially start the template line/station it creates the INIT DSTS number of stations. After that, every time you do a start on the template line, INTVAL DSTS number of stations are created even though the template line/station is already logically started. Problem: The code wasn't checking the logical state of the template station to see if it was already logically. started. Change: Changed it so that when you start the line, it checks the logical state of the template station. If it is logically started, no new stations are created. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-164 SCR #3852 05/15/2022 mmn SVNCPI - rel4^ver1^rel01^20220516 - rel4^ver1^ncp01^20220516 - rel4^ver1^rn01^20220516 - rel4^ver1^sec01^20220516 SVNCPI - rel4^ver0^rel05^20220416 - rel4^ver0^ncp03^20220516 - rel4^ver0^rn01^20220516 - rel4^ver0^sec01^20220516 SVNCPI - rel3^ver4^rel10^20220516 - rel3^ver4^ncp07^20220516 - rel3^ver4^rn04^2022051 - rel3^ver4^sec04^20220516 Reference Case H24-415848 Symptom: SVNCPI dumps with an illegal address trap. Problem: SVNCPI process issued a READ against an internal open to the XPNET Node ($node.#DESTINF) and this failed with an error 2. When this occurs, the NCPI process closes the opens it has to the XPNET node (they will be re-opened on the next command). Immediately after this occurs, an I/O completes from this #DESTINFO file open. The logic that processes this completion did not check to verify that the file is still open and uses data from the I/O tag to access internal structures which are no longer valid, this can create unpredictable errors/memory corruption causing the abend. Change: Added a call to CANCEL to cancel the oldest incomplete operation issued against the file open prior to calling CLOSE to prevent the "late" completion, avoiding the illegal trap abend. Implementation: Install the new SVNCPI file on XPNET subvol. STOP and restart the SVNCPI process. Dependencies: No dependencies. Code Review: CR-XPNET-166 SCR #3857 08/10/2022 des SVNCPI - rel4^ver1^rel02^20220810 - rel4^ver1^rn02^202208106 SVNCPI - rel4^ver0^rel06^20220810 - rel4^ver0^rn02^20220810 SVNCPI - rel3^ver4^rel11^20220810 - rel3^ver4^rn05^20220810 Reference Case H24-383111 Symptom: After stopping a temporary line/lines, if a status command is done on temporary lines, the following message is displayed on the NCPCOM screen for every temporary station that was stopped: Line status failed, int table invalid. Problem: SVNCPI was searching the wrong memory tree during a delete of the temporary line. Change: Changed SVNCPI to search the correct memory tree. Implementation: Install the new SVNCPI file on XPNET subvol. STOP and restart the SVNCPI process. Dependencies: No dependencies. Code Review: CR-XPNET-171 SCR #3856 08/09/2022 mmn SVNCSP - SVNCSP-34-04 - SVTAB-B-34-01 - SVNCSP-40-01 - SVTAB-B-40-01 - SVNCSP-41-02 - SVTAB-B-41-02 SVNCSP24 - SVNCSP-NET24-34-04 - SVTAB-B-34-01 - SVNCSP-NET24-40-01 - SVTAB-B-40-01 - SVNCSP-NET24-41-02 - SVTAB-B-41-02 NCSPREPT - NCSP-REPORT-REL34-03 - SVTAB-B-34-01 - NCSP-REPORT-REL40-01 - SVTAB-B-40-01 - NCSP-REPORT-REL41-02 - SVTAB-B-41-02 Reference: Case H24-437053/03449259 Symptom: Invalid security - on command ALTER DEST *, RTS ON Problem: The logic in the DEST security table was using the wrong VTY when updating the NCSP file for ALTER DEST RTS. Change: Fixed the code to use NCP-VTY-DEST-RTS-ONOFF when updating the NCSP record. Implementation: Install the new modules and update the appropriate NCSP records. Dependencies: No dependencies. Code Review: CR-XPNET-170 SCR #3855 08/04/22 des BASE - REL3^VER4^BASE^REL19^20220804 REL3^VER4^DCOM06^20220804 REL3^VER4^ONCF^STA04^20220804 REL3^VER4^ONCF^LIN03^20220804 BASE - REL4^VER0^BASE^REL14^20220804 REL4^VER0^DCOM05^20220804 REL4^VER0^ONCF^STA03^20220804 REL4^VER0^ONCF^LIN03^20220804 BASE - REL4^VER1^BASE^REL06^20220804 REL4^VER1^DCOM02^20220804 REL4^VER1^ONCF^STA02^20220804 REL4^VER1^ONCF^LIN03^20220804 Reference H24-383111 Symptom: Using temporary stations, if you stop the temporary lines, XPNET fails to creat more temporary stations. If you stop the temporary stations, the new temporary stations are created. When the template station or line is started, the station status has a logical state of STARTED, but the line status shows a logical state of STOPPED. This causes confusion. Problem: XPNET was not correctly handling the stop of the temporary lines. The state of the template line was never changed when starting either it or the template station. Change: Modified XPNET to create new temporary lines/stations when the existing temporary lines are stopped. Modified the code to mirror the state of the temporary station. Since the temporary lines/stations don't ever get a connection, the current state of them is always STOPPED. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-169 SCR #3859 08/24/22 des BASE - REL3^VER4^BASE^REL20^20220824 REL3^VER4^ONCF^STA05^20220824 BASE - REL4^VER0^BASE^REL15^20220824 REL4^VER0^ONCF^STA04^20220824 BASE - REL4^VER1^BASE^REL07^20220824 REL4^VER1^ONCF^STA03^20220824 Reference H24-383111 Symptom: When doing the following command: STATUS STATION *,TCPLISTENLINE Stations that don't have a TCPLISTENLINE would display invalid information. Problem: A move for an invalid length failed to fill the field with spaces. Change: Modified the move statement to use the correct length. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-173 SCR #3862 09/14/2022 des BASE - REL3^VER4^BASE^REL21^20220914 REL3^VER4^ONCF^STA06^20220914 BASE - REL4^VER0^BASE^REL16^20220914 REL4^VER0^ONCF^STA05^20220914 Reference Case H24-448167 Symptom: XPNET is abending with a trap 11 Problem: The network was trying to start a server connection handler ( IPSC ) station. The TCPLISTENLINE contained an entry for a server listener ( IPSL ) line that didn't exist. Change: Check if there is a valid address for the server listener , if zero we now return an invalid internal table error. Note: This fix is already in 4.1 under SCRX902. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-176 SCR #3864 10/13/2022 des BASE - REL3^VER4^BASE^REL22^20221013 REL3^VER4^EXEC05^20221013 BASE - REL4^VER0^BASE^REL17^20221013 REL4^VER0^EXEC05^20221013 BASE - REL4^VER1^BASE^REL08^20221013 REL4^VER1^EXEC02^20221013 Reference Case H24-453279 Symptom: Customer performed the following command: DELIVER STATION *,"STATUS DETAIL" XPNET and ICE-XS were running in the same CPU. Following the deliver command, cpu utilization went to 100%. Problem: The deliver command was sent to each station's endpoint. The WGI stations talking to ICE-XS received an error vector back from ICE-XS. Because the destination of the original mesage was #NETCNTL, the WGI protocol would send the message back to ICE-XS. This echoing continued, utilizing most of the CPU. Change: When XPNET receives a message, if the source is a station and the destination of the message is #NETCNTL, XPNET now routes the message to #DIAG-DEST. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-178 SCR #3867 10/29/2022 mmn XPNET 3.1 BASE - REL3^VER1^BASE^REL46^20221029 - REL3^VER1^ONCF^SYS22^20221029 - REL3^VER1^NSTP09^20221029 - REL3^VER1^LCNS04^20221029 - REL3^VER1^EXEC22^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N31GLBL.GLBL20 NETDDLS - N31GLBL.GDDL07DS NETDC - N31GLBL.GDDL07DC NETDTAL - N31GLBL.GDDL07DT NETDFUP - N31GLBL.GDDL07DZ NETTPLS - N31EMS.EMS13PS NETTPLO - N31EMS.EMS13PO NETETCL - N31EMS.EMS12EA NETEC - N31EMS.EMS12EC NETEDDL - N31EMS.EMS12ES NETETAL - N31EMS.EMS12ET NETECOB - N31EMS.EMS12EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 3.2 BASE - REL3^VER2^BASE^REL19^20221029 - REL3^VER2^ONCF^SYS06^20221029 - REL3^VER2^NSTP04^20221029 - REL3^VER2^LCNS01^20221029 - REL3^VER2^EXEC06^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N32GLBL.GLBL09 NETDDLS - N32GLBL.GDDL06DS NETDC - N32GLBL.GDDL06DC NETDTAL - N32GLBL.GDDL06DT NETDFUP - N32GLBL.GDDL06DZ NETTPLS - N32EMS.EMS01PS NETTPLO - N32EMS.EMS01PO NETETCL - N32EMS.EMS01EA NETEC - N32EMS.EMS01EC NETEDDL - N32EMS.EMS01ES NETETAL - N32EMS.EMS01ET NETECOB - N32EMS.EMS01EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 3.3 BASE - REL3^VER3^BASE^REL24^20221029 - REL3^VER3^ONCF^SYS08^20221029 - REL3^VER3^NSTP04^20221029 - REL3^VER3^LCNS01^20221029 - REL3^VER3^EXEC09^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N33GLBL.GLBL09 NETDDLS - N33GLBL.GDDL03DS NETDC - N33GLBL.GDDL03DC NETDTAL - N33GLBL.GDDL03DT NETDFUP - N33GLBL.GDDL03DZ NETTPLS - N33EMS.EMS02PS NETTPLO - N33EMS.EMS02PO NETETCL - N33EMS.EMS02EA NETEC - N33EMS.EMS02EC NETEDDL - N33EMS.EMS02ES NETETAL - N33EMS.EMS02ET NETECOB - N33EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 3.4 BASE - REL3^VER4^BASE^REL23^20221029 - REL3^VER4^ONCF^SYS04^20221029 - REL3^VER4^NSTP04^20221029 - REL3^VER4^LCNS01^20221029 - REL3^VER4^EXEC06^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N34GLBL.GLBL05 NETDDLS - N34GLBL.GDDL02DS NETDC - N34GLBL.GDDL02DC NETDTAL - N34GLBL.GDDL02DT NETDFUP - N34GLBL.GDDL02DZ NETTPLS - N34EMS.EMS02PS NETTPLO - N34EMS.EMS02PO NETETCL - N34EMS.EMS02EA NETEC - N34EMS.EMS02EC NETEDDL - N34EMS.EMS02ES NETETAL - N34EMS.EMS02ET NETECOB - N34EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 SVNCPI - REL3^VER4^NCP08^20221029 - REL3^VER4^RN06^20221029 - REL3^VER4^REL12^20221029 XPNET 4.0 BASE - REL4^VER0^BASE^REL18^20221029 - REL4^VER0^ONCF^SYS04^20221029 - REL4^VER0^NSTP03^20221029 - REL4^VER0^LCNS02^20221029 - REL4^VER0^EXEC06^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N40GLBL.GLBL02 NETDDLS - N40GLBL.GDDL01DS NETDC - N40GLBL.GDDL01DC NETDTAL - N40GLBL.GDDL01DT NETDFUP - N40GLBL.GDDL01DZ NETTPLS - N40EMS.EMS02PS NETTPLO - N40EMS.EMS02PO NETETCL - N40EMS.EMS02EA NETEC - N40EMS.EMS02EC NETEDDL - N40EMS.EMS02ES NETETAL - N40EMS.EMS02ET NETECOB - N40EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 4.1 BASE - REL4^VER1^BASE^REL09^20221029 - REL4^VER1^ONCF^SYS02^20221029 - REL4^VER1^NSTP02^20221029 - REL4^VER1^LCNS01^20221029 - REL4^VER1^EXEC03^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N41GLBL.GLBL02 NETDDLS - N41GLBL.GDDL01DS NETDC - N41GLBL.GDDL01DC NETDTAL - N41GLBL.GDDL01DT NETDFUP - N41GLBL.GDDL01DZ NETTPLS - N41EMS.EMS03PS NETTPLO - N41EMS.EMS03PO NETETCL - N41EMS.EMS02EA NETEC - N41EMS.EMS02EC NETEDDL - N41EMS.EMS02ES NETETAL - N41EMS.EMS02ET NETECOB - N41EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 Reference: Internal Symptom: N/A Problem: Inconsistent license enforcement across XPNET releases. Change: Added logic to releases 3.1 thru 4.1 to standardize license enforcement. The following enforcement is now standard across releases 3.1 thru 4.1 of XPNET: 1. License expiration warnings will be issued starting 30 days prior to expiration, increasing in frequency as the expiration date nears and is passed. 2. If the license is less than 180 days past expiration XPNET will not cease execution and will be able to be restarted. 3. When the license is 180 days past expiration, XPNET will cease execution and will not be able to be restarted. To distinguish licenses issued before this SCR and those that were issued after, we have incremented a license header informational field (modification number) from 5 to 6. All new shipments of XPNET that include this SCR will be accompanied with a format 6 license with an expiration date that matches the expiration date of your XPNET contract. It is expected that customers will make use of the format 6 license with the version of XPNET containing this SCR. In addition to the standardized enforcement, the following scenarios are accommodated in the new versions of release 3.1 thru 4.1 of XPNET: 1. Use of a version 5 license: a. If the license is not expired, standardized enforcement will be followed. b. If the license contains an expiration date is farther in the future than the end of your XPNET contract, the 180-day temporary allowance will be started. At the end of 180 days, XPNET will cease execution and will not be able to be restarted. c. If the license is expired, the 180-day temporary allowance will be started. At the end of 180 days, XPNET will cease execution and will not be able to be restarted. 2. Use of a version 6 license: a. If the license is not expired, standardized enforcement will be followed. b. If the license is expired, XPNET will continue to start and execute until it reaches 180 days past expiration, at which time XPNET will cease execution and will not be able to be restarted. Customer will be warned via event 6492 every 3 hours which will indicate the number of days remaining before a new license file needs to be installed. 22-11-08;12:57:38.491 \PROD.$P1AN ACI.XPNET.4100 6492 Old format XPNET LICENSE file \PROD.$SYS.XPNET.LI170831 is in use. XPNET Node will stop in 160 days. Contact your ACI customer manager to order a new license. If a new format license file is expired more than 180 days the XPNET node will stop and not restart. This was done to be consistent with all the other licensed ACI products Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Install the new NETTPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Validate the new license file is installed using the LIVERIFY macro. If the most recent license file installed is still the old format the following will be shown: This license expires on (yyyy-mm-dd): 2050-12-30 ******************************************* >>> This is an OLD format License <<< >>> XPNET node will STOP after 180 days <<< ******************************************* Contact your ACI customer manager to order a new license Dependencies: No dependencies. Code Review: CR-XPNET-181 SCR #3873 12/22/2022 mmn NCSPREPT - NCSP-REPORT-REL41-03 NCSPREPT - NCSP-REPORT-REL40-02 NCSPREPT - NCSP-REPORT-REL34-04 Reference: Case H24-470151 Symptom: The report output incorrectly showed a value of "N" for all station access flags for all profiles. Problem: When the report program was modified to support two records per NCSP profile (to handle additional ONCF commands per NCSS user), the station logic did not properly remove one line of code previously used when there was only one record per NCSP profile. This caused the incorrect access flag value to be printed for station commands. Change: Commented out the incorrect line of code. Implementation: Install the new NCSPREPT object and re-run the report. Dependencies: No dependencies. Code Review: CR-XPNET-186 SCR #3859 08/24/22 des BASE - REL3^VER4^BASE^REL20^20220824 REL3^VER4^ONCF^STA05^20220824 BASE - REL4^VER0^BASE^REL15^20220824 REL4^VER0^ONCF^STA04^20220824 BASE - REL4^VER1^BASE^REL07^20220824 REL4^VER1^ONCF^STA03^20220824 Reference H24-383111 Symptom: When doing the following command: INFO STATION *,TCPLISTENLINE Stations that don't have a TCPLISTENLINE would display invalid information. Problem: A move for an invalid length failed to fill the field with spaces. Change: Modified the move statement to use the correct length. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-173 SCR #3868 11/14/2022 des BASE - REL3^VER3^BASE^REL25^20221114 REL3^VER3^DCOM07^20221114 BASE - REL3^VER4^BASE^REL24^20221114 REL3^VER4^DCOM07^20221114 BASE - REL4^VER0^BASE^REL19^20221114 REL4^VER0^DCOM06^20221114 BASE - REL4^VER1^BASE^REL10^20221114 REL4^VER1^DCOM03^20221114 SSLLIBI - T0000H06_03_STGSSLNLIB_18NOV2022_6_0_3_0 STGKM - T0000H06_03_STGKM_30MAR2022_6_0_2_3 T0000H06_03_STGSSLLIB_12OCT2022_6_0_2_17_SPCL Reference Internal Symptom: There are two problems this SCR fixes: - A CERTSREFRESH command is issued and the following log message is seen: ACI_SSL_CERTIFICATE_REFRESH Error 5 for the current Certificate Refresh command. Error 5 is an invalid password. - After a successful CERTSREFRESH command was executed, the customer executed another CERTSREFRESH to go back to the previous certificate. The command seems to work, but it fails to switch back to the previous certificate. Problem: Two things can cause the first problem: - The password being passed to the SSLLIBI routine ACI_SSLCERTIFICATE_REFRESH isn't null terminated, and this routine expects it to be. - In 4.1 only, the code looks at every device in the configuration. We use the last device's definition for the password being passed to the routine. This may not always be valid. The cause for the second problem: - A problem in the SSLLIBI routine ACI_SSLCERTIFICATE_REFRESH. Change: For problem one: - The code makes sure the password is null terminated. - While looping through the devices, when a valid device is found it's information is saved off. We then use that saved information in the call to ACI_SSLCERTIFICATE_REFRESH. For problem two: - A change was made in the SSLLIBI routine Implementation: Install the new BASE, SSLLIBI and STGKM files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-182 SCR #3869 11/30/2022 gjd XPNET 4.1 BASE - REL4^VER1^BASE^REL10^20221114 - REL4^VER1^ONCF^STA04^20221130 SVNCPI - rel4^ver1^rel03^20221130 - rel4^ver1^ncp02^20221130 XPNET 4.0 BASE - REL4^VER0^BASE^REL19^20221114 - REL4^VER0^ONCF^STA06^20221130 SVNCPI - rel4^ver0^rel07^20221130 - rel4^ver0^ncp04^20221130 XPNET 3.4 BASE - REL3^VER4^BASE^REL24^20221114 - REL3^VER4^ONCF^STA07^20221130 SVNCPI - rel3^ver4^rel13^20221130 - rel3^ver4^ncp09^20221130 XPNET 3.3 BASE - REL3^VER3^BASE^REL25^20221114 - REL3^VER3^ONCF^STA06^20221130; SVNCPI - rel3^ver3^rel15^20221130 - rel3^ver3^ncp11^20221130 Reference Case H24-467724 (3486896 ) Symptom: HINFO Station command causes XPNET to Dump. Problem: HINFO command is done on a IPSC station that has a TCPLISTENLINE configred pointing to an existing IPSL Line that does not have a corresponding IPSL Station configured. Code is not checking to ensure that the corresponding station exists and tries to access the station pointer that is set to zero causing the dump. Change: Added code to validate the IPSL station pointer. Code will fail the command and return "no stations configured" to NCPCOM. Implementation: Install the new SVNCPI file on XPNET subvol. STOP and restart the SVNCPI process. Dependencies: No dependencies. Code Review: CR-XPNET-xxx SCR #3871 12/14/2022 mmn BASE - REL4^VER1^BASE^REL10^20221114 - REL4^VER1^EXEC04^20221215 BASE - REL4^VER0^BASE^REL19^20221114 REL4^VER0^EXEC07^20221215 BASE - REL3^VER4^BASE^REL24^20221114 REL3^VER4^EXEC07^20221215 BASE - REL3^VER3^BASE^REL25^20221114 REL3^VER3^EXEC10^20221215 BASE - REL3^VER2^BASE^REL20^20221215 REL3^VER2^EXEC07^20221215 BASE - REL3^VER1^BASE^REL47^20221215 REL3^VER1^EXEC23^20221215 Reference: Case H24-471603 Symptom: Following an ADD NODE command event 6405 was generated every two hours. 22-12-10;13:08:48.475 \SYS1.$P1AN ACI.XPNET.4000 6405 XPNET experienced memory corruption error 2. Process will continue. Problem: As part of the license enforcement changes added by SCR 3867 an additional license verification check was added when an ADD NODE command is done. This logic did not properly reset an internal flag causing a sanity check to fail which generates event 6405. Change: Corrected the ADD NODE logic to fix this issue. NOTE: This does not cause any memory corruption to any message data and the NODE will continue to process transactions, restart and function correctly even though this event is being generated. A work around is to STOP/START the NODE after the ADD NODE command and this event will no longer occur. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-184 SCR #3875 02/10/2023 mmn BASE - REL3^VER4^AUD02^20230210 - REL3^VER4^DCOM08^20230210 - REL3^VER4^ELOG01^20230210 - REL3^VER4^GATE01^20230210 - REL3^VER4^MMGR02^20230210 - REL3^VER4^NSTP05^20230210 - REL3^VER4^PROC02^20230210 - REL3^VER4^QUE02^20230210 - REL3^VER4^ONCF^CJ01^20230210 - REL3^VER4^BASE^REL25^20230210 EAUDPRO - REL3^VER4^EAUD02^20230210 RTSSAT - REL3^VER4^RTS08^20230210 Reference: Internal Symptom: START STATION * command caused XPNET node to abend with a 9902 trap. Problem: The original XPNET 3.4 NDF NODE NEF record was not properly 8 byte word aligned. This was corrected as part of SCR 3867 which caused the size of the NDF record to increase by 4 bytes. This caused the address of the NDF transaction memory structure to shift 4 bytes. In some cases this caused a memory mismatch between modules in BASE and the wrong memory location (i.e. NDF.LINES) could be updated causing the trap to occur. Change: Identified and recompiled all the modules that reference any variables in the NDF transaction area so a memory mismatch does not occur. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-187 SCR #3874 03/01/2023 mmn SVNCSP - SVNCSP-34-05 - SVTAB-A-34-03 - SVTAB-B-34-02 - SVTAB-C-34-01 - SVNCSP-40-02 - SVTAB-A-40-01 - SVTAB-B-40-02 - SVTAB-C-40-01 - SVNCSP-41-03 - SVTAB-A-41-02 - SVTAB-B-41-03 - SVTAB-C-41-02 SVNCSP24 - SVNCSP-NET24-34-05 - SVTAB-A-34-03 - SVTAB-B-34-02 - SVTAB-C-34-01 - SVNCSP-NET24-40-02 - SVTAB-A-40-01 - SVTAB-B-40-02 - SVTAB-C-40-01 - SVNCSP-NET24-41-03 - SVTAB-A-41-02 - SVTAB-B-41-03 - SVTAB-C-41-02 NCSPREPT - NCSP-REPORT-REL34-05 - SVTAB-A-34-03 - SVTAB-B-34-02 - SVTAB-C-34-01 - NCSP-REPORT-REL40-03 - SVTAB-A-40-01 - SVTAB-B-40-02 - SVTAB-C-40-01 - NCSP-REPORT-REL41-04 - SVTAB-A-41-02 - SVTAB-B-41-03 - SVTAB-C-41-02 Reference: Case H24-470151/03489935 Symptom: There are two issues. 1) NODE COMMAND TRACE SSL was not able to be secured. 2) Several commands in the NCSP requestors and report where not properly displayed in alphabetical order. Problem: 1) The index for the TRACE SSL command was not properly incremented, so its entry was overwritten with another command and thus not accessible. 2) Some of the entries were not added to the command table in the correct order. This did not affect the ability to secure the commands, just how they were displayed. Change: 1) Fixed the logic to increment the TRACE SSL index. 2) Reviewed and corrected the order in which commands are added so they are now all in alphabetical order. Implementation: Install the new modules and update the appropriate NCSP records. Dependencies: No dependencies. Code Review: CR-XPNET-188 SCR #3880 03/23/2023 mmn SKELBXL - REL3^VER4^SUTLXL00^20230316 - REL4^VER0^SUTLXL00^20230316 - REL4^VER1^SUTLXL00^20230316 SKELXLST - REL3^VER4^SUTLXL00^20230316 - REL4^VER0^SUTLXL00^20230316 - REL4^VER1^SUTLXL00^20230316 PREGENXL - REL3^VER4^PREXL00^20230316 - REL4^VER0^PREXL00^20230316 - REL4^VER1^PREXL00^20230316 OCAPREGX - S34PRE.OCAX00AS - S40PRE.OCAX00AS - S41PRE.OCAX00AS OXAPREGX - S34PRE.OXAX00AS - S40PRE.OXAX00AS - S41PRE.OXAX00AS OCASKELX - N34SUTL.OCAX00AS - N40SUTL.OCAX00AS - N41SUTL.OCAX00AS OXASKELX - N34SUTL.OXAX00AS - N40SUTL.OXAX00AS - N41SUTL.OXAX00AS Reference: H24-487089/03511009 Symptom: PREGEN fails when building the SPROUTEN file. Problem: The SPROUTE/N file is created as a named extended selectable segment. Selectable segments have a size limit of 127.5 meg. Due to the number of PRADD statements and IPF/CPF records this limit was exceeded causing PREGEN to fail. Change: Created new modules PREGENXL and SKELBXL to create and manage the SPROUTE/N file as a named flat segment which has a size limit of 1.5 gig. Implementation: Install the new PREGENXL module and accelerate the object using the appropriate OCA/OXA obey file. Then rerun PREGENXL using the PRECMD file. Since SKELBXL is run as a user library do the following only after taking appropriate action to avoid library conflicts. Install SKELBXL on the XPNET subvol and accelerate using the appropriate OCA/OXA obey file. Any applications that access the SPROUTE file will need to be altered to use the SKELBXL library after the new PREGENXL has been run to create the SPROUTE file. Dependencies: These changes must be installed at the same time once the flat segment version of the SPROUTE file has been created. If not it could cause applications accessing the SPROUTE file to abend, route incorrectly. Customers that have not exceeded this SPROUTE file size limit will not be impacted and can continue to use PREGEN and SKELB as in the past. Code Review: CR-XPNET-192 SCR #3884 04/17/2023 mmn XPNCSP - N41NCSP.NCSP02TS XPNCSP - N40NCSP.NCSP01TS XPNCSP - N34NCSP.NCSP02TS Reference: Case H24-470151/03489935 Symptom: There are two issues. 1) NODE COMMAND HSMLOCALADDR was not able to be secured. 2) Several commands in the NCSP screen and report where not properly displayed in alphabetical order. Problem: 1) The HSMLOCALADDR command was not properly added to the logic. 2) Some of the entries were not added to the command table in the correct order. This did not affect the ability to secure the commands, just how they were displayed. Change: 1) Fixed the logic to support the HSMLOCALADDR command. 2) Reviewed and corrected the order in which commands are added so they are now all in alphabetical order. Implementation: Install the new modules and update the appropriate NCSP records. Dependencies: None. Code Review: CR-XPNET-195 /need off;/need on SCR3887 05/22/2023 jb Reference: H24-477498 Symptom: Stations get stuck in STOPPING state or DEALLOC_PENDING when viewed from STATUS STATION, DETAIL. Problem: A race condition exists when both sides of a connection are stopped and restarted close to the same time, as we attempt to restart automatically. In this case the client gets stopped first from NCPCOM, when the client is stopped a message is sent to the server that the connection is gone, the server station gets deallocated and started at about the same time. Processing of both use the CONN_CB clearing needed information before deallocate is complete. Change: Code was changed to mark a start command as invalid when the station is in DEALLOC_PENDING state. This allows the deallocate to complete before reusing the connection control block. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-198 SCR #3897 01/23/2024 rak NETCJRD - REL4^VER1^CJRP01^20240123 REL4^VER0^CJRP01^20240123 REL3^VER4^CJRP01^20240123 Reference: H24-5554731 (03592861) Symptom: NETCJRD program produces incomplete or invalid data. Problem: Change in CJ header data size was not reflected in program. Change: Updated globals to reflect length of CJ header changes. Implementation: Install the new NETCJRD. Dependencies: None. Code Review: CR-XPNET-207 SCR #3898 01/04/2024 des BASE - REL3^VER4^BASE^REL28^20240123 REL3^VER4^DCOM09^20240104 BASE - REL4^VER0^BASE^REL22^20240123 REL4^VER0^DCOM07^20240104 BASE - REL4^VER1^BASE^REL14^20240123 REL4^VER1^DCOM04^20240104 Reference: Internal Symptom: After changing the SSLPWD to spaces after it was once set appropriately and trying a CERTSREFRESH or a restart of the node, the node abends. Problem: The SSLLIB is called with a zero length password. Change: Changed the code to not invoke the SSLLIB with a zero length password. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-205 SCR #3901 01/23/2024 jb BASE - REL4^VER1^BASE^REL14^20240123 REL4^VER1^STA06^20240123 BASE - REL4^VER0^BASE^REL22^20240123 REL4^VER1^STA08^20240123 BASE - REL3^VER4^BASE^REL28^20240123 REL3^VER4^STA09^20240123 Reference: H24-567972 Symptom: HINFO on a TCPSL protocol station does not give the TCPLISTENPORT that was configured Problem: The value was not moved into the HINFO structure when the protocol was TCPSL. Change: added code to move the TCPLISTENPORT data into the structure also added code to move the TCPKEEP data for HINFO. Implementation: Install the new BASE file on the XPNET subvol Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-209 s3904 03/07/24 rak BASE - REL4^VER1^BASE^REL15^20240307 REL4^VER1^PROC01^20240307 BASE - REL4^VER0^BASE^REL23^20240407 REL4^VER1^PROC01^20240307 BASE - REL3^VER4^BASE^REL29^20240407 REL3^VER4^PROC03^20240307 Reference: Case #H24-576776/03618372 Symptom: XPNET dumps with trap #6410 after repeatedly reporting error #2 on a process. Problem: The logic for error handling after performing a WRITEREAD to a process did not include specific actions for an error #2. Change: Included error #2 as a fatal error so XPNET will terminate the process with extreme prejudice to avoid looping or recurrence. Implementation: Install new object files and rebuild the network with the new BASE module. Dependencies: XPNET 3.4 and later. Code Review: CR-XPNET-212 s3925�� 09/16/24�� 1.0.01�� rak RPCGEN - REL1_VER0_RPCG01_20240916 - REL1_VER0_XNCG01_20240916 Reference: Case H24-609288 ( 03655260 ) Symptom: RPCGEN failing compiles with large RPC source files. Problem: Buffer was too small for some files and second read was not processed correctly. Change: Increased FREAD BUFFSIZE to ensure handling of files up to 128K sized and implemented. Also, updated XMPL globals to include all functions to avoid errors/warnings during compilation. Implementation: Install new RPCGEN. Code Review: CR-XPNET-232 Dependencies: none